쿠버네티스 컨트롤러

쿠버네티스 아키텍처

레플리카 셋(Replica Set)

쿠버네티스의 레플리카셋은 정해진 수의 동일한 포드가 항상 실행되도록 관리한다. 마스터 노드의 kube-scheduler가 각 노드의 자원과 현재 상태에 맞춰서 적절하게 분배된다. 노드 장애 등의 이유로 포드를 사용할 수 없다면 다른 노드에서 포드를 다시 생성한다.


따라서 동일한 포드를 안정적으로 여러 개 실행할 수 있고 워커 노드에 장애가 생기더라도 정해진 개수의 포드를 유지할 수 있다. 

 

쿠버네티스 컨트롤러 오브젝트

 

처음에는 replication controller라는 오브젝트가 레플리케이션 업무를 담당했지만 deprecated 됐고 replicaset이 사용이 된다. 이 둘의 제일 큰 차이는 추후 설명할 레이블 셀렉터에 있다.

 

레클리카셋 사용하기

 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx-pods-label
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx-pods-label
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

 

nginx 웹서버 3개를 레플리카셋으로 구성해 실행시키는 YAML 파일이다. spec에 replicas는 동일한 포드를 몇 개 유지시킬 것인지를 설정한다. 위 예시에서 3개로 명시했기 때문에 클러스터에 총 3개의 동일한 포드가 실행된다.

 

matchLabels는 해당 label을 가지고 있는 포드의 개수를 replicas 개수만큼 보장한다는 뜻이다. 아래 template에 명시된 포드의 설정값들의 labels을 동일하게 해줘야만 개수가 보장된다. 따라서 쿠버네티스에서 label은 라벨 그 이상의 의미를 갖고 있다.

 

### 라벨과 함께 오브젝트를 출력하는 명령어
kubectl get pods --show-labels

### 라벨의 key 값을 갖고있는 오브젝트를 출력하는 명령어
kubectl get pods -l app

### 라벨의 key 와 value를 갖고있는 오브젝트를 출력하는 명령어
kubectl get pods -l app=my-nginx-pods-label

 

레이블 셀렉터

레플리케이션 컨트롤러는 일치성 기준이며 레플리카셋은 집합성 기준이다. 일치성 기준의 레플리케이션 컨트롤러의 레이블 셀렉터는 key와 value의 값이 모두 일치해야하지만 집합성 기준의 레플리카셋은 보다 다양한 셀렉터를 지원한다.

 

matchLabels 레이블 셀렉터

 

spec:
  selector:
    matchLabels:
      key: value

matchLabels로 레이블 셀렉터를 사용하면 레플리케이션 컨트롤러와 동일하게 동작한다

 

matchExpressions 레이블 셀렉터

 

spec:
  selector:
    matchExpressions:
    - key: <string>
      operator: <In | NotIn | Exists | DoesNotExist>
      values:
      - <string>

 

matchExpressions 필드는 집합성 기반 레이블 셀렉터를 지원합니다.

.spec.selector.matchExpressions.key: 선택할 레이블의 키 이름을 지정

.spec.selector.matchExpressions.values: 레이블의 값을 지정

.spec.selector.matchExpressions.operator: 연산자

 

연산자의 종류는 다음과 같습니다.

- In: 레이블의 키와 값이 지정된 값으로 일치해야 합니다

- NotIn: 레이블의 키와 값이 지정된 값과 일치하지 않아야 합니다

- Exists: 레이블의 키가 포함되어야 합니다 (값은 해당사항 없음)

- DoesNotExist: 레이블의 키가 포함되지 않아야 합니다

- Exists와 DoesNotExist는 레이블의 키값만 매칭 합니다. 즉, values 항목을 설정하지 않습니다.

 

 

디플로이먼트(Deployment): 레플리카셋, 포드의 배포를 관리

 

쿠버네티스의 디플로이먼트는 레플리카셋의 상위 개념이다. YAML 파일을 작성할때 레플리카셋 YAML파일의 kind에 Deployment라고만 명시하면 디플로이먼트를 생성하게 된다. 그렇다면 레플리카셋과 완벽히 동일하다고 생각이 드는데 왜 디플로이먼트를 쓸까 의문이 들지만 사실 디플로이먼트는 배포에 중점을 두고 있다. 나중에 설명할 롤링 업데이트 및 배포 중심의 서비스를 관리하기 좋다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

 

위의 예시가 디플로이먼트를 생성하는 YAML 파일이다. 위의 레플리카셋 YAML 파일과 다른 점이 거의 없다. 디플로이먼트를 생성하면 자동으로 레플리카셋이 생성되고 replicas 개수에 맞는 포드도 워커 노드에 분배되어 생성된다.

 

디플로이먼트라는 이름의 Deploy에서 알 수 있듯이 디플로이먼트는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다. 예를 들어 애플리케이션을 업데이트할 때 레플리카셋의 변경 사항을 저장하는 리비전을 남겨 롤백을 가능하게 해 주고, 무중단 서비스를 위해 포드의 롤링 업데이트의 전략을 지정할 수도 있다.

 

YAML 파일로 디플로이먼트를 생성할 때 --record 옵션을 추가해 생성하면 이 해당 디플로이먼트의 업데이트 기록을 남겨주는 기능을 추가하게 해 준다.

 

kubectl create -f deployment-nginx.yaml --record

 

애플리케이션의 버전이 업데이트되어 포드의 이미지를 변경해야 한다고 가정하면 set image 명령어를 사용해 업데이트할 수 있다.

 

kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record

 

이런 식으로 업데이트하면 새로운 포드가 생성이 된다. 레플리카셋도 하나가 더 생성이 된다. 하지만 전에 생성됬던 레플리카셋도 삭제되지 않고 존재한다. 디플로이먼트의 기록을 보려면 rollout history 명령어로 확인한다.

 

kubectl rollout history deployment my-nginx-deployment

 

만약에 이전 버전의 레플리카셋으로 되돌리는 롤백을 하고 싶다면 rollout undo 명령어를 실행한다. 옵션으로 --to-revision은 되돌리려는 리비전의 번호를 입력한다.

 

kubectl rollout undo deployment my-nginx-deployment --to-revision=1

 

### 디플로이먼트의 상태값을 알려준다
kubectl rollout status deployment my-nginx-deployment

### 디플로이먼트 업데이트를 일시정지한다
kubectl rollout pause deployment my-nginx-deployment

### 디플로이먼트 업데이트를 재시작한다
kubectl rollout resume deployment my-nginx-deployment