소개

Deployment에는 변경사항을 롤백하는 기능이 있습니다. 이번에는 롤백의 동작을 확인해 보겠습니다.

변경 내역 확인

현재 상태 확인

먼저 현재 상태를 확인합니다. 현재는 지난번 가 끝난 후의 상태입니다.

$ kubectl get deployments.apps
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
sample-pod4   4/4     4            4           23h
$ kubectl get rs -o wide
NAME                     DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES       SELECTOR
sample-pod4-597898b879   4         4         4       23h   nginx        nginx:1.16   app=nginx-dep,pod-template-hash=597898b879
sample-pod4-65fb458568   0         0         0       19h   nginx        nginx:1.17   app=nginx-dep,pod-template-hash=65fb458568

Deployment 이름 "sample-pod4"에는 두 개의 ReplicaSet이 있습니다.
현재 Image 버전이 "1.16"인 ReplicaSet이 사용되고 있습니다.

변경 내역 확인

kubectl rollout 명령으로 확인합니다.

$ kubectl rollout history deployment sample-pod4
deployment.apps/sample-pod4
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

각 개정에 대한 세부 정보도 확인합니다.

$ kubectl rollout history deployment sample-pod4 --revision 2
deployment.apps/sample-pod4 with revision #2
Pod Template:
  Labels:       app=nginx-dep
        pod-template-hash=65fb458568
  Containers:
   nginx:
    Image:      nginx:1.17
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

$ kubectl rollout history deployment sample-pod4 --revision 3
deployment.apps/sample-pod4 with revision #3
Pod Template:
  Labels:       app=nginx-dep
        pod-template-hash=597898b879
  Containers:
   nginx:
    Image:      nginx:1.16
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

그림으로 나타내면 다음과 같은 느낌입니다.



그림에서는 Revision.1도 나타내고 있습니다만, 같은 ReplicaSet에 되돌리면, 과거의 Revision은 표시되어 있지 않습니다.
Revision.1이 표시되는지 확인해 봅니다.

$ kubectl rollout history deployment sample-pod4 --revision 1
error: unable to find the specified revision

표시되지 않았습니다.

롤백

Revision.2로 롤백합니다.

$ kubectl rollout undo deployment sample-pod4 --to-revision 2
deployment.apps/sample-pod4 rolled back
$ kubectl get rs -o wide
NAME                     DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES       SELECTOR
sample-pod4-597898b879   0         0         0       23h   nginx        nginx:1.16   app=nginx-dep,pod-template-hash=597898b879
sample-pod4-65fb458568   4         4         4       19h   nginx        nginx:1.17   app=nginx-dep,pod-template-hash=65fb458568

1.16의 ReplicaSet은 '0'이 되고 1.17의 ReplicaSet은 '4'입니다.
또한 인수로 Revision을 지정하지 않으면 이전의 Revision으로 돌아갑니다.

histroy를 확인해 보겠습니다. Revision.4가 새로 추가되었습니다.

$ kubectl rollout history deployment sample-pod4
deployment.apps/sample-pod4
REVISION  CHANGE-CAUSE
3         <none>
4         <none>

Revision.2로 돌아가는 대신 "Revision.2의 ReplicaSet으로 새로운 Revision으로 돌아가기"가 올바른 것 같습니다.
그림으로 하면 다음과 같이 되어 있습니다.

세부정보 확인

kubectl describe에서 자세한 내용을 확인해 보겠습니다.

$ kubectl describe rs sample-pod4-65fb458568
Name:           sample-pod4-65fb458568
Namespace:      default
Selector:       app=nginx-dep,pod-template-hash=65fb458568
Labels:         app=nginx-dep
                pod-template-hash=65fb458568
Annotations:    deployment.kubernetes.io/desired-replicas: 4
                deployment.kubernetes.io/max-replicas: 5
                deployment.kubernetes.io/revision: 4
                deployment.kubernetes.io/revision-history: 2
・・・

Annotation의 Revision이 "4"로 되어 있고, "revision-history"라는 새로운 Annotation이 설정되어 있고, 값은 "2"로 되어 있습니다.

1.16 분도 상세를 확인해 보겠습니다.

$ kubectl describe rs sample-pod4-597898b879
Name:           sample-pod4-597898b879
Namespace:      default
Selector:       app=nginx-dep,pod-template-hash=597898b879
Labels:         app=nginx-dep
                pod-template-hash=597898b879
Annotations:    deployment.kubernetes.io/desired-replicas: 4
                deployment.kubernetes.io/max-replicas: 5
                deployment.kubernetes.io/revision: 3
                deployment.kubernetes.io/revision-history: 1
・・・

이쪽은, revision가 「3」, revision-history가 「1」이 되어 있군요.

여기서 깨달은 것은 Revision 1->2, 2->3, yaml 파일을 업데이트하고 kubectl apply로 변경했습니다.
Revision 3->4는 kubectl rollout에서 변경되었습니다.
명령은 다르지만 동작과 Annotation 설정은 동일합니다.

실제의 운용을 생각하면, kubectl rollout 커멘드를 사용하는 것보다, yaml 파일을 갱신해 kubectl apply 커멘드로 반영하는 것이 CI/CD 파이프라인으로 취급하기 쉬울까 생각합니다.

record 옵션

매뉴얼에는 다음의 기재가 있습니다. 이 record 옵션을 사용해보십시오.

비고 : 실행 된 명령을 kubernetes.io/change-cause라는 주석에 기록하기 위해 -record 플래그를 지정할 수 있습니다. 이것은 미래의 문제를 조사하는 데 효과적입니다. 예를 들어, 각 Deployment 리비전에서 실행된 명령을 볼 때 유용합니다.
쿠베르 자고 s. 이오

확인

일단 기존 Deployment를 삭제하고 같은 yaml 파일로 적용합니다. 그 때 --record 옵션을 부여합니다.

$ kubectl apply -f sampleDep.yaml --record
deployment.apps/sample-pod4 created

yaml 파일을 편집하고 다시 적용합니다.

$ kubectl apply -f sampleDep.yaml --record
deployment.apps/sample-pod4 configured
$ kubectl get rs -o wide
NAME                     DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES       SELECTOR
sample-pod4-597898b879   0         0         0       2m40s   nginx        nginx:1.16   app=nginx-dep,pod-template-hash=597898b879
sample-pod4-65fb458568   3         3         3       12s     nginx        nginx:1.17   app=nginx-dep,pod-template-hash=65fb458568

기록을 확인합니다.

$ kubectl rollout history deployment sample-pod4
deployment.apps/sample-pod4
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=sampleDep.yaml --record=true
2         kubectl apply --filename=sampleDep.yaml --record=true

--record 옵션을 부여하지 않고 apply했을 때의 이력은 이쪽입니다.

$ kubectl rollout history deployment sample-pod4
deployment.apps/sample-pod4
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

CHANGE-CAUSE의 컬럼에 실행한 커멘드가 표시되어, 무엇을 했는지를 알게 되네요.

리비전에 대해 자세히 알아보세요.

$ kubectl rollout history deployment sample-pod4 --revision 2
deployment.apps/sample-pod4 with revision #2:frowning2:
Pod Template:
  Labels:       app=nginx-dep
        pod-template-hash=65fb458568
  Annotations:  kubernetes.io/change-cause: kubectl apply --filename=sampleDep.yaml --record=true　　<--これが追加されてる。
  Containers:
   nginx:
    Image:      nginx:1.17
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Annotations 항목이 추가되었습니다.

--record 옵션을 부여하면 조작이 기록되므로 붙이는 것이 좋지만, 없으면 곤란한가 하면 거기까지는 아닌 것 같습니다.

요약

Deployment 롤백 동작을 확인했습니다.
컨테이너는 배포 기회가 많기 때문에 그만큼 롤백 할 기회도 있다고 생각합니다. 실제로는 배포도 롤백도 자동화해 운용한다고 생각합니다만, 기본적인 동작은 이해해 두고 싶네요.