Argo CD를 이용한 다양한 배포 방식을 지원하는 라이브러리 : Argo Rollouts
Argo Rollouts에 대해서 알아보자.
Argo CD를 이용하여 배포할 시, Blue/Green 형태로 배포하기 위해 Argo 진영 라이브러리인 Argo Rollouts을 사용할 수 있다.
Blue/Green 배포란 아래와 같다.
쿠버네티스에서 Blue는 기존 Pod라고 볼 수 있고, Green은 새롭게 배포해야 할 Pod라고 보면 된다.
기본적인 쿠버네티스의 배포 방식은 위의 Blue/Green 배포 방식과 비슷해 보이지만 좀 다르다.
먼저, Pod가 2개 이상인 경우에는 각 Pod 1개씩 Rolling update한다.
즉, 아래 순서와 같이 동작하게 된다.
- Blue 2개 / Green 0개
- Blue 1개 / Green 1개 ← 해당 시점에서 service의 엔드포인트에 2개 버전의 Pod가 존재함.
- Blue 0개 / Green 2개(새로운 Blue로 등극)
위와 같은 동작은 2번의 경우 삭제되어야 할 Blue Pod 1개와 새롭게 배포되어야 할 Green Pod 1개가 동일한 service를 통해 트래픽을 전달받게 된다. 따라서 2개 버전의 Pod가 잠깐이나마 동시에 동작하는 시점이 존재하게 된다.
이를 막고자 한다면, 그리고 Argo CD를 통해 배포를 하고 있다면 Argo Rollouts 라는 라이브러리를 사용하여 해결할 수 있다.
Argo Rollouts 라이브러리를 사용하여 Blue/Green 방식으로 배포하도록 수정하면 아래와 같이 동작하게 된다.
- Blue 2개 / Green 0개
- Blue 2개 / Green 2개 ← 해당 시점에서 service의 엔드포인트는 Green 2개로 바로 절체된다.
- Blue 0개 / Green 2개
이 때, Blue/Green 배포 방식에서는 active service라는 실제 프로덕션을 라우팅하는 service 리소스와, preview service라는 롤아웃 대기 상태의 Pod들을 라우팅하는 service 리소스가 있다.
따라서 active로 롤아웃 하기 전에 먼저 preview service를 통해 새로운 Pod가 정상적으로 잘 띄워졌고 잘 작동하는지 체크한 후에 active로 전환(롤아웃)할 수 있다.
또한 Argo Rollouts는 Canary 배포도 지원한다.
Canary 배포란, 서버의 트래픽 일부를 새로운 버전으로 분산해서 조금씩 테스트 해본 후, 오류가 없이 정상적이라면 전체를 배포하는 방법이다.
예를 들어, 기존 Pod가 10개 있었다면 Canary 배포 시, 아래와 같이 동작하게 된다.
- 기존 Pod 10개 / 새 Pod 0개
- 기존 Pod 9개 / 새 Pod 1개
- (일정 기간 테스트 : A/B 테스트)
- 오류가 없다면 → 기존 Pod 0개 / 새 Pod 10개
- 오류가 있다면 → 기존 Pod 10개 / 새 Pod 0개
Rolling / Blue-Green / Canary 이 세가지 배포 전략에 대해서 쉽게 설명해주는 글은 아래를 참고한다.
설치
먼저 Argo Rollouts를 설치하기 위해서는 kubectl이 설치되어 있어야 하고, kubeconfig 파일이 ~/.kube/config 디렉터리 내에 존재하고 있어야 한다.
그리고 쿠버네티스 클러스터 내부에 Argo CD 대시보드가 세팅되어 있어야 한다.
Argo CD가 무엇인지 그리고 세팅을 어떻게 하는지 궁금하다면 아래 글을 참고해보자.
본론으로 돌아오자.
Argo Rollouts를 설치하기 위해서는 아래 명령어를 실행한다.
만약 쿠버네티스 버전이 1.14 버전 이하라면, Argo Rollouts를 설치할 때 --validate=false옵션을 사용하여 적용해야 한다.
이는 쿠버네티스 1.15 버전에 도입된 새로운 CRD 필드를 사용하기 때문에 발생하며, 이는 하위 API 서버에서 기본적으로 거부되기 때문이다.
+참고 :
GKE를 사용하는 경우 아래 명령어를 통해 권한을 부여해야 한다.
이제 실제 Argo Rollouts를 적용하기 위해서 manifest를 어떻게 작성해야 하는지 확인해보자.
이해하기 쉽게 일단 manifest 파일의 예제를 살펴보자.
아래는 Blue/Green 배포 방식을 위한 manifest 설정의 예시 이다.
아래는 Canary 배포 방식을 위한 manifest 설정의 예시 이다.
각 배포 방식별로 더 자세한 옵션 내용을 확인하고 싶으면 아래 링크를 참고한다.
Blue/Green 테스트
그럼 실제로 Blue/Green 배포를 해보자.
먼저 Argo CD 대시보드에 아래 링크를 참고하여 그림과 같이 테스트 전용 앱을 만든다.
(참고로 아래 리포지토리의 manifest는 helm을 사용하고 있다. Argo CD 대시보드에서 기본적으로 호환된다.)
필자는 test라는 네임스페이스를 설정해서 위 manifest를 적용했다.
아래와 같이 Pod, Service, 그리고 각 Service의 상세 정보를 확인해보았다.
일단 아래 그림은 첫번째 배포(Blue)가 완료된 모습이다.
브라우저를 통해 해당 Pod로 접속하면 아래와 같이 화면을 확인할 수 있다.
지금은 Blue 버전으로 돌아가고 있는 모습이다.
자, 이제 Green 버전으로 Blue/Green 배포를 해보자.
우리가 apply 했던 manifest에 tag값만 green으로 변경해서 다시 apply 해보자.
그럼 아래와 같이 green 버전의 Pod 2개가 새롭게 생성된 것을 확인할 수 있다.
아래와 같이 새롭게 생성된 Pod(172.28.9.237, 172.28.1.149)가 rollouts-demo-preview 라는 서비스에 하나씩 할당되는 중이다.
새롭게 생성된 Green Pod는 Rollout 되기 전에 preview 서비스에서 확인할 수 있다.
일정 시간이 지나 Green Pod 2개가 완벽하게 Running 상태가 되면 아래와 같이 확인할 수 있다.
이제 Green Pod 2개는 완벽히 정상적으로 Running 되고 있으므로, preview 서비스에서 active 서비스로 넘어왔다.
그리고 기존 Blue Pod 2개는 active 서비스에서 해제되었다.
브라우저를 통해 active 서비스로 접속하면 아래와 같이 Blue에서 Green으로 넘어온 것을 확인할 수 있다.
이제 Blue Pod 2개는 terminate를 준비한다.
기존 Blue Pod 2개가 완벽히 Terminate되면 아래와 같이 확인할 수 있다.
참고
- git webhook을 사용하여 기본 3분 이후 sync 체크를 하는 것이 아닌, push 감지 후 바로 sync 되도록 하기 위한 설정법
