$ kubectl argo rollouts completion bash | tee /home/ubuntu/.kube/kubectl-argo-rollouts > /dev/null
$ vi ~/.bash_profile
source '/home/ubuntu/.kube/completion.bash.inc'
source '/home/ubuntu/.kube/kubectl-argo-rollouts'
PATH=/home/ubuntu/bin:$PATH
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
3. 최초 App 배포 (Blue Deployment)
초기 app (blue)을 배포한다. 이전 글에서 사용된 seungkyua/nginx:blue 이미지를 배포한다. 단 replicas 를 0 으로 배포한다. 이렇게 배포하면 실제 pod 는 실행되지 않지만 pod template 은 배포된 상태가 된다. pod template 은 나중에 rollout 에서 참조하여 사용한다.
그리고 blue deployment app 에 웹접속이 가능하게 ingress 를 배포한다. ingress 를 배포하더라도 아직 웹 접속은 불가능하다. 앞에서 deployment 의 replicas 를 0 으로 생성했기 때문에 실행되고 있는 pod 가 없기 때문이다. (나중에 접속을 위해서 /etc/hosts 에 nginx-blue-green.taco-cat.xyz 를 등록해 놓자)
이제 배포가 완료되면 아래와 같이 리소스가 생성되었음을 확인할 수 있다. rollout pod 와 rollout 에서 사용하는 ReplicaSet 이 생성되어 있음을 알 수 있다.
$ kubectl argo rollouts list rollout
NAME STRATEGY STATUS STEP SET-WEIGHT READY DESIRED UP-TO-DATE AVAILABLE
nginx-rollout BlueGreen Healthy - - 2/2 2 2 2
$ kubectl get pods,deploy,rs
NAME READY STATUS RESTARTS AGE
pod/nginx-rollout-85c4bfb654-jmts7 1/1 Running 0 2m29s
pod/nginx-rollout-85c4bfb654-s46sm 1/1 Running 0 2m29s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-blue-green 0/0 0 0 4m50s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-blue-green-8b4f9cddb 0 0 0 4m50s
replicaset.apps/nginx-rollout-85c4bfb654 2 2 2 2m29s
웹으로 접속하면 아래와 같은 화면을 볼 수 있다.
혹은 curl 로도 확인할 수 있다.
$ curl nginx-blue-green.taco-cat.xyz
--- output ---
<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>
Rollout dashboard 에는 아래와 같이 나온다.
4. App 업그레이드 배포 (Green Deployment)
app 을 수정하여 배포해 보자. app 은 Deployment 를 수정해서 배포하면 된다.
Deployment 가 업그레이드 되어 배포했기 때문에 Rollout 이 이를 인식하고 Green 에 해당하는 추가 Pod 와 ReplicaSet 을 생성한다. 그리고 Rollout 리소스의 상태는 Paused 가 된. (앞에서 Rollout 리소스 배포 시에 autoPromotionEnabled 는 false 로 하였기 때문이다)
$ kubectl argo rollouts list rollout
NAME STRATEGY STATUS STEP SET-WEIGHT READY DESIRED UP-TO-DATE AVAILABLE
nginx-rollout BlueGreen Paused - - 2/4 2 2 2
Pod 와 ReplicaSet 을 조회해 보면 아래와 같다. Blue 해당하는 ReplicaSet 1 개, Pod 2개, Green 에 해당하는 ReplicaSet 1개 Pod 2 개가 떠 있는 것을 알 수 있다.
Rollout Dashboar 는 아래와 같은 Pause 상태이다.
5. Rollout 진행 완료 (promote)
완전히 Green 으로 변경하려면 Rollout 을 promote 하여 최종 적용을 하던지 abort 하여 중단, 혹은 undo 하여 Pause 보다 이전 단계이 최초 Blue app 배포 단계로 돌아가는 방법이 있다.
아래의 그림에서 보듯이 Canary 배포를 진행할 때 일시적으로 배포를 홀딩한 상태에서 new version 에 대한 배포가 성공되었는지를 Metric 으로 판단하여 안전하게 배포를 완료할 수 있다. (metric 수집과 쿼리는 Prometheus 를 포함하여 다양한 모니터링 툴을 지원한다.)
Metric 을 통해 배포의 성공 여부를 판단하여 rollback 할 것인지, 계속 진행할 것인지를 결정할 수 있다는 것이 중요한 키 포인트다. 왜냐하면 쿠버네티스의 롤링 업데이트는 readiness 로 배포 성공여부를 판단하는데 이는 Metric 보다 판단하기에 부족할 수 있고, 중간에 에러가 발생하면 멈출 수 는 있지만 자동으로 rollback 되지는 않기 때문이다.
# kubectl argo rollouts get rollout rollouts-demo --watch
Basic rollout Canary 업그레이드
# kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
rollout 전략이 처음 step 은 20% 만 변경하는 것이기 때문에 5개의 replica 중에 1개만 old version(blue) 이고 4 개는 new version(yellow) 이다. 그리고 현재는 pause (일시멈춤) 상태로 더이상 rollout 배포가 진행되지 않고 있다.
Basic rollout Canary 업그레이드 계속 진행
# kubectl argo rollouts promote rollouts-demo
promote 로 계속 rollout 업그레이드를 진행하면 점차 new version 이 revision:2 영역인 canary 로 replica 개수를 증가시키는 것을 볼 수 있다. duration 을 10으로 주었기 때문에 10 초 단위로 20% 씩 자동으로 올려준다.
일정 시간이 다 지나면 전체가 전부 다 업그레이드 된다.
argo rollout 은 metric 으로 정의한 성공 여부에 따라 배포를 계속 진행할 것인지 아니면 abort 시킬 것인지를 자동으로 결정할 수 있다.