파드를 업데이트 한다는 것은, 파드에 배포된 컨테이너의 내용을 변경하여 새로운 버전을 배포한다는 것과 동일한 의미이다. https://secjong.tistory.com/57 에서 다루었듯, Deployment 를 이용해 파드를 업데이트하면, 이전 배포 버전의 Replicaset 는 삭제되지 않고 살아있게 된다. 디플로이먼트의 롤백은 실제로는 이전 버전의 레플리카셋으로 전환하는 것이다.

 

롤백을 하기 위해 어떤 버전으로 롤백을 하고자 하는지 정해야 하므로, 아래 커맨드를 이용해 디플로이먼트의 변경 이력을 확인한다. 리비전이 곧 버전이 된다.

$ kubectl rollout history deployment sample-deployment
REVISION  CHANGE-CAUSE
3         <none>
4         <none>
5         <none>

 

하지만, 디플로이먼트 revision 인 3, 4, 5 값만으로는 어떤 배포버전을 의미하는 것인지 알기 힘들다. 실제로 실무에서는 커맨드로 직접 롤백하지 않고 형상관리 툴과 연결된 CI/CD 도구를 이용해서 git commit message 등을 조회하여 어떤 revision 이 어떤 배포 건인지 확인할 수 있기 때문에 직접 확인하지 않지만, 공부를 위해 확인해보자.

 

아래 커맨드를 이용해 특정 리비전이 가진 파드 템플릿 정보를 알 수 있다.

$ kubectl rollout history deployment sample-deployment --revision 3
deployment.apps/sample-deployment with revision #3
Pod Template:
  Labels:	app=sample-app
	pod-template-hash=7457fb97b6
  Containers:
   nginx-container:
    Image:	nginx:1.17
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>
  Node-Selectors:	<none>
  Tolerations:	<none>

 

또한 아래 커맨드를 통해 replicaset 의 자세한 정보에서도 revision 을 확인할 수 있다.

$ kubectl describe replicasets.apps sample-deployment-7457fb97b6
Name:           sample-deployment-7457fb97b6
Namespace:      default
Selector:       app=sample-app,pod-template-hash=7457fb97b6
Labels:         app=sample-app
                pod-template-hash=7457fb97b6
Annotations:    deployment.kubernetes.io/desired-replicas: 3
                deployment.kubernetes.io/max-replicas: 4
                deployment.kubernetes.io/revision: 3
Controlled By:  Deployment/sample-deployment
Replicas:       0 current / 0 desired
Pods Status:    0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=sample-app
           pod-template-hash=7457fb97b6
  Containers:
   nginx-container:
    Image:         nginx:1.17
...

 

Annotations 의 deployment.kubernetes.io/revision 에서 revision 번호를, Pod Template 에서 컨테이너 이미지 버전 등을 확인할 수 있다. 우리는 이렇게 조회된 nginx 1.17 버전을 원한다고 가정하고, revision 3 으로 롤백을 진행하고 결과를 확인해보자.

$ kubectl rollout undo deployment sample-deployment --to-revision 3
deployment.apps/sample-deployment rolled back

$ kubectl get deployments.apps sample-deployment -o wide
롤백된 버전 확인

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

$ kubectl get rs -l app=sample-app
# 해당 리비전의 replicaset 이 사용중인지 확인
NAME                           DESIRED   CURRENT   READY   AGE
sample-deployment-5d6c4c4b76   0         0         0       48m
sample-deployment-5f6db9bfb9   0         0         0       49m # 이전 레플리카셋
sample-deployment-7457fb97b6   3         3         3       47m # 현재 레플리카셋

 

위에 언급했듯, 실제 서비스 환경에서는 rollout undo 를 사용하지 않고, 매니페스트 파일의 형상을 이전 버전으로 되돌린 후에 다시 apply 하는 방식을 더 많이 쓴다. 이 측면이 형상관리 이력을 남긴다는 측면에서 더 이롭고, 동일한 파드 정의로 되돌리는 것이므로 파드 템플릿 해시값이 동일하게 적용되기 때문에 해당 리비전의 레플리카셋이 재활용된다는 것은 완벽히 동일하기 때문이다.

블로그 이미지

망원동똑똑이

프로그래밍 지식을 자유롭게 모아두는 곳입니다.

,