[Kubernetes] Argo Rollouts를 이용한 배포 - Blue/Green, Canary

Argo Rollouts

Argo Rollouts는 ArgoCD와 다른 독립적인 솔루션으로, ArgoCD 없이도 사용할 수 있다.

이는 ArgoCD의 의존성인 Git 없이도 사용할 수 있다는 것을 의미한다.

 

Argo Rollouts 자체적으로 대시보드도 제공하고,

단지 ArgoCD가 있으면 ArgoCD에서도 Argo Rollouts를 실행할 수 있는 버튼이 생길 뿐이다.

 

쿠버네티스는 자체 리소스도 있지만, 누구나 커스텀 리소스를 만들 수 있는 CRD라는 기능을 제공한다.

Argo Rollouts를 쿠버네티스에 설치하면 이를 통해 Rollout이라는 컨트롤러를 만들 수 있게 된다.

 

Deployment의 배포 전략에 Recreate와 Rolling Update가 있는 것처럼,

Rollout의 배포 전략에는 Blue/Green과 Canary가 존재한다.

 

Blue/Green 배포

Blue/Green 배포에서는 Rollout에서 Service를 2개 지정하도록 되어 있다.

• Active Service: 실제 서비스 사용자가 들어오는 Service
• Preview Service: 업그레이드 중에 신규 버전으로만 들어갈 수 있는 Service

배포가 진행중이 아닐 때에는 Preview Service도 Active Service와 동일하게 기존 Pod로 연결되어 있다.

 

Rollout의 태그를 변경하고 배포를 시작하면 아래와 같은 업그레이드 동작이 시작된다.

1. 새로운 버전의 ReplicaSet이 생성되고, Pod들이 만들어진다.
2. Preview Service의 연결이 새로운 버전의 Pod들로 변경된다.
   • Pod에 label을 추가하고, Service의 Selector에도 동일하게 구성하여 연결한다.
     (lable명: rollouts-pod-template-hash)
3. QA 담당자가 Preview Service를 통해 테스트한다.
4. 문제 없으면 Promote 명령을 통해 Active Service의 Pod 트래픽을 새로운 Pod들로 변경한다.
5. 기존 버전의 Pod들을 삭제한다.

 

Canary 배포

Canary 배포는 Blue/Green 배포와는 다르게 쿠버네티스 기본 리소스들로만 구현할 수는 없다.

Argo Rollouts 사용 시에도 섬세한 트래픽 조절은 NginX나 Istio를 통해 구현해야 한다.

 

Blue/Green 배포와는 다르게 Canary 배포에서 Service는 하나만 지정한다.

Rollout의 태그를 변경하고 배포를 시작하면 아래와 같은 업그레이드 동작이 시작된다.

1. 새로운 버전의 ReplicaSet이 생성되고, setWeight 비율 만큼 새로운 Pod들이 만들어진다.
2. pause 속성에 설정한 시간만큼 배포 대기를 수행한다. (비어있으면 무한 대기)
   • 무한 대기 시 Promote 명령이 발생하면 다음 배포 로직을 수행한다.
3. pause가 끝나면 다음 setWeight속성에 맞춰서 Pod를 재구성한다.
4. setWeight가 없다면 새로운 버전으로 배포를 마무리한다.

---

출처

https://www.inflearn.com/course/쿠버네티스-어나더-클래스-지상편-sprint1

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런