Deployments - Rolling Back a Deployment

Rolling Back a Deployment

rollout 될 때마다 rollout history가 남고 이를 이용해 롤백이 가능함. 여기서는 nginx 버전에 오타를 내고 배포하는 예시로 진행했음. 해당 버전이 아예 없어서 ImagePullBackOff 에러가 발생.

 

Checking Rollout History of a Deployment

1. 먼저 아래 명령어로 revisions를 확인

kubectl rollout history deployment.v1.apps/nginx-deployment

2. 특정 revision의 상세 내용은 아래 명령어로

kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2

Rolling Back to a Previous Revision

이전 버전이면 --to-revision 없이 실행하면 되고, 특정 revision이면 아래와 같이 --to-revision 명시

kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

Scaling a Deployment

아래 명령어로 sacle 할 수 있음.

kubectl scale deployment.v1.apps/nginx-deployment --replicas=10

기존 desired를 넘어가는 replicas도 되나? 됨. 어차피 새로운 rs로 만드는 거라.

 

horizontal Pod autoscaling이 활성화되어 있다면 아래와 같이 cpu 사용율 기반의 autoscaling도 설정 가능.

kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80

Proportional scaling

rollout 도중 autoscaler가 scale 할 경우 Deployment Controller는 risk 방지 차원에서 여분의 replicas를 기존 rs에서 운영하게 된다. 이걸 proportional scaling이라고 함. 말 그대로 일정 비율을 항상 유지하는 것임.

 

예를 들면, 10개의 replicas가 있고 maxSurge=3, maxUnavailable=2 라고 하자.

 

unresolved 태그로 이미지 업데이트를 시도하면, 새로운 rs를 만들고 기존 rs의 pod은 scale down하는데 2개까지만 down되고 멈춘다. maxUnavailable=2 때문임.

 

이러고 나서는 진행이 안됨. unresolved image를 요청했으니 당연한 결과. 아마 Proportional scaling이 어떻게 진행되는가 보여주기 위해 unresolved image 태그를 예제로 잡은 듯. 정상적인 태그라면 replicas를 15개로 잡고(15가 어떤 산술로 나온 건지는 모르겠음) old rs, new rs에 비율을 맞춰서 pod을 생성하면서 새로운 rs가 정상이라고 가정되면 new rs로 최종적으로 이관됨.

 

결론은 Deployment 업데이트 시 이슈 없게 적절히 업데이트 한다 이 말이야.