🚀 Deployment로 무중단 배포하기 (롤링 업데이트 & 롤백)

디플로이먼트: 레플리카셋의 상위 오브젝트

실제 운영 환경에서 레플리카셋을 YAML로 직접 정의하는 경우는 거의 없다. 대신 디플로이먼트를 YAML에 정의하고, 디플로이먼트가 레플리카셋을 생성, 교체, 삭제한다.

디플로이먼트는 레플리카셋의 상위 오브젝트로, 하나의 디플로이먼트는 시점에 따라 여러 개의 레플리카셋을 가질 수 있다. 디플로이먼트가 필요한 이유는 새 버전으로의 전환과 이전 버전으로의 복귀를 레플리카셋 단독으로는 처리할 수 없기 때문이다.

디플로이먼트와 함께 생성되는 레플리카셋과 파드

레플리카셋과 디플로이먼트의 YAML은 거의 동일하다. kind만 ReplicaSet에서 Deployment로 바뀌고, 나머지 replicas, selector, template 필드는 같은 의미로 동작한다.

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

위 YAML 파일을 적용하면 디플로이먼트 1개, 레플리카셋 1개, 파드 3개가 한 번에 만들어진다. kubectl get을 통해 계층별로 확인할 수 있다.

$ kubectl apply -f deployment.yaml
deployment.apps/my-nginx-deployment created


$ kubectl get deployment # 또는 짧게 kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   3/3     3            3           10s


$ kubectl get replicasets
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-6d4dd4d565   3         3         3       10s


$ kubectl get pods
NAME                                            READY   STATUS    RESTARTS   AGE
my-nginx-deployment-6d4dd4d565-48mzf            1/1     Running   0          10s
my-nginx-deployment-6d4dd4d565-84q8s            1/1     Running   0          10s
my-nginx-deployment-6d4dd4d565-br8s8            1/1     Running   0          10s

레플리카셋의 이름은 <디플로이먼트 이름>-<해시> 형식으로 생성되고, 파드의 이름은 그 위에 임의 접미사가 붙는다. 이 명명 규칙은 소유 관계를 그대로 반영한다. (파드의 owner는 레플리카셋이고, 레플리카셋의 owner는 디플로이먼트)

삭제할 때도 같은 계층이 그대로 적용된다. kubectl delete deploy my-nginx-deployment 한 번으로 디플로이먼트, 레플리카셋, 파드가 모두 삭제된다. 파드만 직접 지우면 레플리카셋이 즉시 파드를 다시 생성하고, 레플리카셋만 지우면 디플로이먼트가 새 레플리카셋을 생성한다. 따라서 정리는 항상 가장 위 계층인 디플로이먼트에서 시작해야 한다.

디플로이먼트의 두 책임: 롤링 업데이트와 롤백

레플리카셋만 있어도 파드 개수는 자동으로 유지된다. 그러나 이미지를 새 버전으로 바꾸는 일은 사람이 직접 처리해야 한다.

새 레플리카셋을 만들고, 이전 레플리카셋의 replicas를 한 단계씩 줄이고, 트래픽이 끊기지 않도록 교체 속도를 조절하고, 문제가 생기면 다시 되돌리는 절차다. 이러한 절차를 컨트롤러가 자동으로 수행하도록 만든 것이 디플로이먼트다.

디플로이먼트는 두 가지를 책임진다.

1. 새 버전 배포 시 이전 파드를 한꺼번에 종료하지 않고 일부씩 교체해 무중단 상태를 유지하는 롤링 업데이트
2. 배포 시점마다 직전 상태를 리비전(revision)으로 보존했다가 한 명령으로 이전 상태로 되돌릴 수 있는 롤백

정리하면 디플로이먼트는 "원하는 파드 개수를 유지한다"라는 레플리카셋의 책임 위에 "버전 사이를 안전하게 이동한다"라는 책임을 한 단계 더 얹는다.

이미지 변경의 결과: 새 레플리카셋의 생성

디플로이먼트의 이미지를 바꾸는 방법은 세 가지다. 어느 방법을 쓰더라도 결과는 같다.

# 1. YAML 파일의 image 필드를 수정한 뒤 다시 apply한다. 
$ kubectl apply -f deployment.yaml --record


# 2. 명령어로 이미지만 직접 교체한다.
$ kubectl set image deployment/my-nginx-deployment my-nginx=nginx:1.11 --record


# 3. 디플로이먼트 정의를 edit으로 직접 편집한다. 
$ kubectl edit deployment my-nginx-deployment

--record 플래그는 변경에 사용한 명령어를 리비전의 메모로 남긴다. 이후 kubectl rollout history에서 어떤 명령이 어떤 리비전을 만들었는지 추적할 때 쓰인다.

* 현재 버전 기준 --record 플래그는 deprecated 상태이며, 같은 효과를 내려면 디플로이먼트의 kubernetes.io/change-cause 어노테이션을 직접 다는 방식이 권장된다.

이미지를 바꾸면 디플로이먼트는 새 파드 템플릿 해시를 계산하고, 그 해시가 붙은 새 레플리카셋을 만든다. 그리고 이전 레플리카셋의 replicas를 단계적으로 줄이고 새 레플리카셋의 replicas를 단계적으로 늘려 파드를 교체한다.

교체가 끝난 뒤에도 이전 레플리카셋은 사라지지 않고 replicas: 0 상태로 남는다. 롤백 시 다시 살리기 위해서다.

$ kubectl get replicasets
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-6d4dd4d565   0         0         0       10m  # 이전 (1.10)
my-nginx-deployment-6d4dd4d566   3         3         3       1m   # 신규 (1.11)

현재 트래픽을 받는 레플리카셋이 어느 것인지는 kubectl describe deployment my-nginx-deployment의 NewReplicaSet 항목에서 확인할 수 있다. 0으로 줄어든 이전 레플리카셋들은 같은 출력의 OldReplicaSets에 나열된다.

리비전 롤백의 메커니즘

지금까지의 배포 이력은 kubectl rollout history로 확인할 수 있다.

$ kubectl rollout history deployment my-nginx-deployment
deployment.apps/my-nginx-deployment
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=deployment.yaml --record=true
2           kubectl set image deployment/my-nginx-deployment my-nginx=nginx:1.11 --record=true

CHANGE-CAUSE는 앞 섹션의 --record 플래그가 남긴 메모로, 이 메모가 없으면 <none>으로 표시되어 어떤 변경이 어느 리비전을 만들었는지 분간하기 어려워진다.

특정 리비전으로 돌리려면 kubectl rollout undo에 --to-revision을 지정한다. 인자 없이 사용하면 직전 리비전으로 돌아간다.

# 직전 리비전으로 롤백
$ kubectl rollout undo deployment my-nginx-deployment


# 특정 리비전으로 롤백
$ kubectl rollout undo deployment my-nginx-deployment --to-revision=1

이 명령어가 하는 일은 새 레플리카셋을 만드는 것이 아니다. 디플로이먼트는 지정한 리비전에 대응하는 이전 레플리카셋을 찾아 replicas를 다시 늘리고, 현재 활성 레플리카셋의 replicas를 줄인다.

즉, 롤백도 롤링 업데이트와 동일한 메커니즘으로 동작한다. revisionHistoryLimit을 넘겨 사라진 리비전으로는 되돌릴 수 없는 이유가 여기에 있다.