[k8s] Argo Rollouts: Blue Green Deploy

이전 포스트
https://blog.naver.com/sssang97/223134344138

Argo Rollouts을 사용해서 Blue-Green 배포를 구성하는 방법을 다뤄보겠다.

우선 서비스가 2개 있어야 한다.
하나는 프로덕션 배포용 엔드포인트고, 하나는 새 버전을 배포할때 테스트할 용도의 엔드포인트다.

apiVersion: v1
kind: Service
metadata:
  name: prod-service
spec:
  selector:
    app: bg-server
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: test-service
spec:
  selector:
    app: bg-server
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

둘다 일단 하나의 앱(bg-server)만 가리키게 해놨다.

그리고 Rollout을 사용해서 리소스를 정의한다.
Rollout는 Deployment와 유사한 형태의 커스텀 컨트롤러다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout 
metadata:
  name: bg-server
spec:
  replicas: 3
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: bg-server
  template:
    metadata:
      labels:
        app: bg-server
    spec:
      containers:
      - name: bg-server
        image: myyrakle/node-server-for-test:1
        imagePullPolicy: Always
        ports:
        - containerPort: 80
  strategy:
    blueGreen: 
      activeService: prod-service
      previewService: test-service
      autoPromotionEnabled: false

blueGreen 필드에 궁금해할만한 대부분의 옵션이 들어있다.
방금 정의한 2개의 서비스를 연결하고 autoPromotionEnabled를 false로 했다.
autoPromotionEnabled는 새 버전이 문제없이 떴을때 blue-green 스위칭을 자동으로 할 것인지에 대한 것이다.

자동으로 하게 해도 좋지만, 일단은 테스트를 위해 수동으로 하게 했다.

이미지 myyrakle/node-server-for-test:1는 내가 테스트용으로 말아둔 간단한 서버다.
이제 저걸 myyrakle/node-server-for-test:2로 올리면서 배포를 수행해볼 것이다.

일단 저 초기 구성대로 리소스들을 게시한다.
그럼 Rollout을 기반으로 레플리카 Pod가 3개 뜰 것이고

서비스로 실행도 잘 될 것이다.

배포를 진행하지 않는 상태에서는 둘다 같은 Pod 그룹을 가리킨다.

kubectl argo rollouts list rollout

Blue-Green 배포 실행

ArcoCD로 gitops 기반을 구성해뒀다면, 그냥 이미지 버전만 수정하면 된다.

그러면 가동을 시작해서

추가 파드를 띄우고

test용 서비스에 새 배포 버전이 라우팅될 것이다.

그리고 Pod 프로비저닝이 완료되면 정지 상태가 된다.

근데 이건 autoPromotionEnabled를 꺼놔서 그렇고, 켜놨다면 자동으로 스위칭을 수행할 것이다.
지금은 저걸 수동으로 스위칭해보겠다.

다음과 같이 CLI를 사용해서 변경을 트리거하면 된다.

그러면 프로덕션 서비스도 스위칭이 될 것이고

기존 버전도 내려가고

배포가 끝날 것이다.

무중단 배포

그런데 저대로 autoPromotionEnabled만 켜기에는 구성에 문제가 좀 있다.
따로 뭘 설정하지 않았기 때문에 Pod들만 다 뜨면 바로 갈아버린다는 것인데, Pod가 뜨는 것과 그 안에서 실제 서버가 다 뜨는지는 별개이기 때문이다...

가장 간단하게 적용할 수 있는 방법은 autoPromotionSeconds으로 스위칭을 수행하기 전에 대기시간을 넣어주는 것이다.
지금 내 서버가 뜨는 시간이 어지간해서는 10초 안에 다 끝날 것 같다. 하면 이렇게 10초를 넣어주면 된다.

Health Check

하지만 저것만으로는 부족할 수 있다.
새로 뜬 버전이 항상 완벽하게 실행된다는 보장이 있는가? 갑자기 세팅이 꼬여서 500이 뜰 수도 있지 않은가?

이 때문에, 보통 스위칭을 하기 전에 새 버전에 대한 Health Check로 검증을 수행하는 것은 꽤나 기본적인 작업이다.

이를 위해서는 먼저 AnalysisTemplate으로 검증을 위한 정의를 만들어줘야 한다.
보통은 프로메테우스와 연계해서 상태확인을 하는 편이다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 5m
    # NOTE: prometheus queries return results in the form of a vector.
    # So it is common to access the index 0 of the returned array to obtain the value
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus.example.com:9090
        query: |
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m]
          )) /
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m]
          ))

그리고 그걸 가져다가 prePromotionAnalysis에 등록해주면 끝이다.

참조
https://argoproj.github.io/argo-rollouts/features/bluegreen/
https://argo-rollouts.readthedocs.io/en/stable/features/analysis/