92. Rolling Updates and Rollbacks

Deployment를 처음 생성하면 Rollout이 트리거된다
새로운 롤아웃은 새로운 Deployment Revision을 만든다 - 예를 들어 Revision 1

• 나중에, 앱이 업그레이드되면 (즉, 컨테이너의 버전이 새로운 버전으로 올라가면)
• 새로운 롤아웃이 트리거되고,
• 새로운 디플로이먼트 리비전이 생성된다 - 예를 들어 Revision 2

Rollout 상태 보기: kubectl rollout status deployment/myapp-development
Rollout 히스토리 보기: kubectl rollout history deployment/myapp-development

Deployment Strategy

1. 있는 인스턴스를 다 날리고 새 인스턴스를 만든다 ("Recreate")
   • 당연히 downtime이 발생함
   • 당연히 쿠버의 기본값은 아님 (쓸 수는 있음)
2. 인스턴스를 하나하나씩 업데이트함 ("Rolling Update")
   • downtime이 발생하지 않음
   • 기본값임

Deployment를 어떻게 업데이트할것인가

업데이트의 종류가 무엇인가?

• 컨테이너 이미지의 버전을 올리는 걸 말하는건가?
• label을 변경하는 걸 말하는건가?
• 아니면 Replica의 수를 변경하는 걸 말하는건가?

아무튼 이미 Deployment definition file이 있으니까, 이러한 업데이트가 뭐든 간에 파일을 수정하고 나서 kubectl apply 를 돌리면 되는것이다.

예를 들어, 컨테이너 이미지의 버전을 올리려면 yaml 파일을 열어서

   spec:
     containers:
     - name: asdf
       image: nginx:1.7.1 => nginx:latest

같은 식으로 변경 후 저장한 뒤에, kubectl apply -f deploy.yaml을 넣는다.

그러면 자동으로 새로운 Rollout과 Deployment의 새 리비전이 생성된다.

(kubectl set image deployment/deployment-name asdf=nginx:latest같이 Imperative하게 수정하는 것은 가능하지만, 앞에서 다뤘듯이 이러면 YAML 파일은 원본 상태 그대로 남아서 나중에 귀찮아질 수 있다)

Recreate v. RollingUpdate

kubectl describe로 디플로이먼트의 상태를 보면,

• Recreate에서는 Replica Set의 수를 0으로 만들어버린 뒤에 다시 원본 숫자로 돌리는 데 반해,
• RollingUpdate에서는 기존 Replica Set의 수를 하나씩 줄이면서, 새로운 Replica Set의 수를 하나씩 올리는 식으로 대응하고 있음을 볼 수 있다.

Rollback

kubectl rollout undo deployment/dep-name

롤백을 하면 RollingUpdate의 역순으로, 그러니까 새로운 ReplicaSet의 레플리카 수를 하나씩 줄이면서 옛날 ReplicaSet을 하나씩 늘리는 방식으로 진행한다.