Argo rollouts 고급 배포 전략 적용 - 1편 (canary, blue green) 기본 개념

이번에는 쿠버네티스 환경에서 고급 배포 전략을 쉽게 적용할 수 있는 Argo rollouts에 대해 포스팅 하겠다.

 

쿠버네티스 기본 배포 방식 - Rolling update

쿠버네티스에선 기본적으로 Rolling update 방식으로 배포를 진행한다.

 

Rolling update

• 이전 버전의 pod들을 점진적으로 업데이트 하는 방식
• 새로운 버전의 pod를 생성하고, 이전 버전의 pod를 제거하는 방식
• 모든 pod들이 다운되지 않게 때문에, 애플리케이션이 다운되는 문제를 해결함
• 그러나, 이전 버전과 최신 버전의 pod들이 공존하는 문제가 있음

 

---

 

Argo rollouts를 이용하여 적용할 수 있는 배포방식 blue- green과 canary 배포 방식에 대해 알아보자.

 

 

blue-green

새로운 버전의 애플리케이션을 기존 버전과 병행하여 배포하고, 트래픽을 전환하여 안정성과 신뢰성을 유지하는 전략

 

 

1. blue (v1) 버전인 애플리케이션을 배포한다.
2. 새로운 버전 (green, v2) 의 애플리케이션이 추가로 배포된다.
3. 새로운 버전 (green, v2) 의 애플리케이션으로 트래픽이 변경된다. / 이 단계에서 테스트가 이루어지며, 문제가 발생했을 경우, 이전 버전으로 롤백을 진행한다.
4. 테스트가 완료된 후 새로운 버전의 애플리케이션으로 배포가 완료된다.

 

pod 상태와 blue-green 배포 전략

 

blue-green 배포가 이루어지는 과정 중의 pod의 상태를 관찰하면서, 어떤식으로 blue-green 배포 전략이 이루어지는지 알아보자.

 

1. blue 버전인 active 애플리케이션이 배포된 상태이다.
2. 새로운 버전으로의 변경상태가 감지된다.
3. 변경된 상태(green)의 pod (preview)가 추가로 배포된다. (revision 2)
   • 이 상태에서 active는 blue 상태를 라우팅하고, preview는 green 상태를 라우팅한다.
4. active 애플리케이션을 새로운 버전으로 배포를 완료하기 전, suspended 상태가 되며, 새로운 버전으로의 배포를 기다 리는 상태가 된다.
5. promotion이 진행되면, active 애플리케이션 역시, green 버전을 라우팅한다.
6. 배포가 완료되면, 이전 revision의 replicas가 0이 되어, blue 상태의 pod들이 종료된다.

 

---

canary

기존 버전의 트래픽을 새로운 버전으로 점진적으로 늘려가며 테스트, 배포하는 방식

 

 

1. 버전 1의 애플리케이션이 배포된 상태이다.
2. 새로운 버전(버전 2)의 애플리케이션을 배포하고, 일부 트래픽을 새로운 버전의 애플리케이션으로 라우팅한다.
3. 점진적으로 새로운 버전의 애플리케이션으로 트래픽을 라우팅하며, 테스트를 진행해 나간다. 문제가 발견되면, 이전 버전으로 롤백을 진행한다.
4. 버전 2 애플리케이션으로 모든 트래픽을 전환하여, canary 배포가 완료된다.

 

 

pod 상태와 canary 배포 전략

 

우선 3가지 개념에 대해 알아보고 넘어가자.

 

먼저, Argo rollouts 에서 기본적으로 트래픽이 어떻게 전환되는지 알아야 한다.

 

기본적인 동작 방식으론, 전환하고자 하는 버전의 pod 수를 늘려가며, 사용자가 원하는 비율의 트래픽이 전환될 수 있는 방식으로 동작된다는 것을 알고있자!

 

자 그러면, 우리는 rollout.yaml 에서 canary 배포의 전체 step만큼의 replicas의 수를 설정해야 함을 알 수 있다.

ex) 20%씩 점진적으로 트래픽을 전환하고자 하면, 전체 replicas는 5가 되어야 한다.

 

이해가 안된다면, 직접 argoCD혹은 k9s에서 pod가 어떻게 생성되고 소멸하는지 관찰해보자.

 

---

두번째는 experiment이다.

 

experiment은 새로운 버전의 트래픽을 시험하기 위해 생성되는 pod이다.

 

사용자는 이 pod로 접근하여, 새로운 버전의 트래픽을 받고 있는 pod를 manual하게 테스트할 수 있다.

 

이를 통해, rollout 중에 사용자는 production 환경에 영향을 미치지 않고, 문제를 사전에 발견할 수 있다.

 

---

세번째는 analysis이다.

 

analysis는 사용자가 원하는 단계에서 사용자가 설정한 metirc을 수집하고, 해당 metirc을 관찰하여 rollout을 진행시킬지, 중단할 지 결정하는데 사용된다.

 

experiment와 달리, 구체적인 metirc을 통해 rollout 상태를 판단하므로 자동적인 방법이라 할 수 있다.

 

---

 

 

이제 canary 배포가 이루어지는 과정 중의 pod의 상태를 관찰하면서, 어떤식으로 canary 배포 전략이 이루어지는지 알아보자.

 

replicas: 4 / setWeight: 25인 경우를 가정해보자.

 

1. production 서비스의 버전 1 트래픽이 100인 상황이다.
2. 새로운 버전으로의 변경 상태가 감지된다.
3. revision1의 pod가 4개에서 3개가 되며, revision2의 pod가 새롭게 1개 생성된다. (25% 전환)
4. 이때부터 사용자는 experiment가 생성한 pod를 통해 manual하게 새로운 버전의 트래픽을 테스트할 수 있다.
5. 혹은 analysis를 통해 수집한 metric을 통해 rollout을 진행 혹은 중단할 수 있다.
6. analysis 혹은 experiment를 통과하면 다음 step으로 넘어간다.
7. revision 2로의 pod 수를 증가시켜, 트래픽을 점진적으로 전환한다.(앞의 과정인 3~6 반복)
8. 트래픽이 완전히 revision2로 전환되며, 배포가 완료된다.

 

 

일단, 오늘은 여기까지...

 

다음 포스팅은 Argo rollouts를 진행하며 겪었던 문제점들과 헷갈렸던 개념들 및 Argo rollouts 컴포넌트의 세부적인 내용들에 대해 다뤄보겠다.