서론

애플리케이션을 무중단으로 배포하는 방법으로는 Rolling, Blue/Green, Canary 방식이 가장 대표적인 방법이라고 생각된다.

현재 Kubernetes 에서 기본적으로 지원하는 배포 방식은 Rolling 방식으로 새로운 서버가 생성되면 일괄로 기존 서버가 삭제되는 방식을 사용한다. 해당 방식도 나쁜 방식은 아니지만 새로운 서버에 문제가 발생할 경우 롤백하기가 굉장히 번거로워진다.

따라서 보통 운영 환경에서는 Blue/Green 배포와 Canary 배포를 많이 사용하는 것으로 알고 있는데 오늘은 그 중에서 Canary 배포를 AWS EKS 와 Argo CD 에 적용하는 방법에 대해서 알아볼 예정이다.

무중단 배포 방식에 대한 설명은 다른 블로그에 자세하게 설명이 되어있으므로 제가 살펴봤던 블로그 링크만 걸고 추가적인 설명은 하지 않겠습니다.

• https://reference-m1.tistory.com/211

해당 내용으로도 부족하다면 구글링으로 더 찾아보시면 될꺼 같습니다!

본론

먼저, Argo CD 와 AWS EKS 는 설정이 전부 되어있다는 가정으로 시작할 예정입니다. 설정이 안되어있으면 이전 섹션을 통해서 설정을 진행 한 후 해당 본문으로 돌아오시면 될꺼 같습니다.

Argo CD Rollouts 설치

Argo CD 에서 공식으로 지원하는 Progressive delivery 툴이 존재합니다.
공식 홈페이지 내용을 기반으로 설명드리도록 하겠습니다.

먼저, AWS EKS 에 Argo CD Rollouts Controller 를 설치해줍니다. 설치 명령어는 다음과 같습니다.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

네임스페이스는 별도의 설정을 하지 않는 이상 argo-rollouts 으로 고정해서 생성하고 해당 네임스페이스에 설치해주셔야 됩니다. 꼭 다른 네임스페이스에 설치해야 되는게 아닌 이상은 변경하지 않고 그대로 명령어를 입력해주시면 됩니다.

그 다음 Argo CD Rollouts 사용을 좀 더 편리하게 해주는 kubectl 플러그인이 존재하는데 선택사항이라고 나와있지만 모든 설명이 플러그인 사용으로 나와있어서 설치해주시는걸 권장드립니다. 설치 방법은 다음과 같습니다.

kubectl 명령을 이용하는 서버에 해당 플러그인을 설치해주시면 됩니다. 저의 경우 배스천 서버를 통해서 EKS 에 접근하기 때문에 배스천 서버에 해당 플러그인을 설치합니다. (Linux OS 기준)

⚙️ 공식 홈페이지에서 제시하는 설치 방법

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-amd64
chmod +x ./kubectl-argo-rollouts-darwin-amd64
sudo mv ./kubectl-argo-rollouts-darwin-amd64 /usr/local/bin/kubectl-argo-rollouts

위의 방식대로 했는데 Unknown command error 'argo' 뭐시기가 뜨시면 아래 방식으로 설치를 해보시면 정상적으로 될겁니다.

⚙️ 내가 제시하는 설치 방법

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
sudo install -o root -g root -m 0755 kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

다른 버전으로 설치하고 싶은 경우 해당 링크에서 원하는 버전으로 curl 명령을 이용해서 설치하시면 됩니다.

마지막으로 잘 설치가 되었는지 확인하기 위해서 아래 명령을 입력합니다.

$ kubectl argo rollouts version
kubectl-argo-rollouts: v1.2.0-rc2+7b69058
  BuildDate: 2022-02-24T22:32:47Z
  GitCommit: 7b690580f69fd491f40c15b3ff4031f13bdae332
  GitTreeState: clean
  GoVersion: go1.17.6
  Compiler: gc
  Platform: linux/amd64

Canary 배포용 YAML 파일 작성

이제 설정은 전부 끝나고 Canary로 배포할 수 있도록 YAML 파일을 작성해야 한다. 일단 예제 파일을 바탕으로 설명을 할 예정이고 예제 파일은 해당 깃허브 페이지에서 가져왔습니다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout # Rollout으로 생성
metadata:
  name: canary-rollout
spec:
  replicas: 8
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: canary
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - name: canary-rollouts-demo
        image: particule/simplecolorapi:1.0
        imagePullPolicy: Always
        ports:
        - containerPort: 5000
  # 이 부분에서 카나리로 지정
  strategy:
    canary:
      maxSurge: "25%"    # canary 배포로 생성할 pod의 비율
      maxUnavailable: 0  # 업데이트 될 때 사용할 수 없는 pod의 최대 수
      steps:
      - setWeight: 25    # 카나리로 배포된 서버로 전송해야될 트래픽 비율
      - pause: {}        # AutoPromotion Time (하단 설명 참조)
---
kind: Service
apiVersion: v1
metadata:
  name: canary-service
spec:
  selector:
    app: canary
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5000
    nodePort: 30081
  type: NodePort

보통 pod 를 배포하기 위해서 kind 를 Deployment 로 생성해서 사용하였을텐데 Canary 배포를 사용하려면 kind 를 Rollout 으로 변경해주고 strategy 를 설정해주어야 한다. strategy 가 추가되는 부분 말고는 Deployment 에서 작성하는 설정을 그대로 작성해주면 됩니다.

위의 파일에서 Auto Promotion 이라는 말이 있는데, 새로운 서버가 maxSurge 에 적힌 퍼센티지에 따라서 그 수만큼 배포가 되는데, 새로운 서버가 Canary 배포된 후 얼마나 시간이 흐른 뒤 새로운 서버로 전부 배포할까요? 라는 설정이다.

따라서 pause에 10분으로 설정해두면 새로운 서버가 Canary로 배포된 후 10분 뒤에 기존 서버가 점진적으로 삭제되면서 새로운 서버가 생성되는 것을 말한다.

추가로 pause에는 다음과 같이 설정이 들어갈 수 있습니다.

- pause: { duration: 30 }  # 30초
- pause: { duration: 30s } # 30초
- pause: { duration: 30m } # 30분
- pause: { duration: 30h } # 30시간
- pause: {}                # Auto Promotion 옵션 비활성화
- pause: { duration: -10 } # 잘못된 옵션

결과

따라서 해당 YAML 파일을 Argo CD Application 을 생성해서 배포하면 다음과 같은 모습을 가집니다.

replicas 를 8로 설정해두었기 때문에 8개의 pod가 생성된 모습을 볼 수 있다.

여기서 YAML 파일에 이미지 태그 버전을 변경해서 새롭게 서버를 띄우도록 하면 다음과 같은 모습으로 서버가 생성된다. (ex. container -> image 에 적혀있는 1.0 을 2.0으로 변경한다.)

위에 빨간색 부분이 새롭게 Canary 배포로 생성된 새로운 서버이다. maxSurge가 25%로 설정되어 있고 replicas 가 8 로 되어있기 때문에 8 * 25 / 100 을 계산하면 2 가 나온다. 따라서 2개의 새로운 서버만 띄워져 있는 모습을 볼 수 있다.

여기서 pause 값에 시간이 정해져 있으면 그 시간만큼 시간이 흐른 뒤 자동으로 파란색 부분에 있는 기존 서버를 삭제하고 빨간색 부분에 새로운 서버가 8개로 점진적 생성이 된다.

만약 수동으로 promote 하고 싶을 경우 다음 명령을 입력해서 promote 할 수 있다.

kubectl argo rollouts promote \
canary-rollout (YAML 파일에서 metadata에 적은 name 값) \
-n canary(자신이 생성한 네임스페이스 위치)

$ kubectl argo rollouts promote canary-rollout -n canary
rollout 'canary-rollout' promoted

이렇게 하면 kubernetes 에서도 Argo CD 를 이용하여 Canary 배포를 진행할 수 있다. Blue/Green 배포도 이용할 수 있으므로 궁금하신 분들은 구글링을 통해서 우선 살펴보시면 될거 같습니다!

결론

Canary 배포로 바꾸는데 굉장히 어려울줄 알았던 반면에 플러그인으로 손쉽게 바뀌는 모습을 보고는 살짝 놀랬다. 하지만 주의할 점으로 새로운 서버와 기존 서버가 공존하는 만큼 API 호환성에 대해 더 신경써야 할 것 같아 보인다.

새로운 서버에는 v2 버전으로 API가 전부 작성되어있어서 기존 서버에 생성된 v1 이 호환되지 않는다면 setWeight 에 설정된 25% 트래픽에서 대해서는 에러가 발생할 것이기 때문이다.

이점만 유의해서 진행한다면 좋은 배포 방식이 되지 않을까 싶습니다.

이번에 가장 헤맨 부분이 플러그인 설치하는 부분에서 엄청 헤맸는데 공식 홈페이지 방식대로 설치하면 계속 'Unknown command' 에러가 떠서 계속 찾다가 kubectl은 어떻게 설치하나 살펴봤더니 다른 방식으로 설치하고 있는걸 캐치했고 그 방식대로 하니까 적용이 되었다. (1시간 정도 헤맸거 같다.)

아무쪼록 빠르게 발견해서 금방 해결할 수 있어서 다행이다.

두서없고 긴 글 읽어주셔서 감사합니다. 총총 🏃🏻‍♀️