[Kubernetes] ArgoCD 사용해보기 (3) - ArgoCD Rollouts를 이용한 배포

Rollouts 설치하기

빌드하기

▶ Jenkins > Dashboard > add-on > deploy-argo > 파라미터와 함께 빌드

DEPLOY_TYPE : helm_upgrade TARGET_ARGO : argocd-rollouts

▶ values-dev.yaml 파일

Rollouts의 대시보드 사용은 기본 값이 false입니다.
대시보드를 사용해 볼 것이기 때문에 enabled속성을 true로 주어 사용해보고자 합니다.

controller:
  replicas: 1
    dashboard:
      enabled: true
    service:
      type: NodePort
      portName: dashboard
      port: 3100
      targetPort: 3100
      nodePort: 30003

▶ 설치 확인

Rollouts을 이용한 Blue/Green 아키텍처

Deployment를 이용한 Blue/green동작 방식과는 다소 다릅니다.
거의 유사한데 그 과정이 생략된 것이라고 생각하시면 됩니다.

 

지난 게시글에서 해본 Deployment를 이용했을 경우 Blue/Green 배포 방식을 생각해보죠.

 

1. v1에 관련된 Deployment, Service을 생성
2. v2에 관련된 Deployment, Service을 생성
3. QA 담당자가 v2에 관련된 테스트가 끝남
4. v1의 Serivce의 selector를 v2를 바라보게 수정
5. v1에 관련된 Deployment, Service를 삭제

기억하시나요??

 

그럼 이제 Rollouts을 이용한 동작을 설명하겠습니다.

 

Rollouts에서는 Pod을 생성할 때 2개의 Service를 만들게 됩니다.
첫번째로 Service-active, 두번째로 Service-preview이 두가지를 만드는데요.

 

초기에는 이 두 Service는 v1버전의 Pod를 함께 바라봅니다.
이 후 Git의 rollout.yaml파일에 변경감지가 일어나면 v2버전에서 사용할 ReplicaSet과 Pod를 만들게 됩니다.

 

그러면 Serivce-preview는 v2의 Pod을 바라보게 되는 것이죠.
유저는 Service-active로 인해 v1을 사용중이지만, QA담당자는 Service-preview를 통해 v2에 관련한 테스트를 진행할 수 있게 되는 것이죠.

 

테스트가 완료되고 Promote명령어 실행하면 Rollouts가 알아서 Service-active가 v2인 Pod을 바라보도록 수정하고 v1의 Pod을 제거합니다.

 

동작방식은 똑같죠??

 

하지만 Deployment에서 했던 2번, 4번, 5번을 우리가 할 필요없이 클릭한번에 해결 할 수 있다는 장점이 생긴겁니다.

 

아래 이미지를 바탕으로 설명한 부분을 한번 더 쉽게 이해해 보시죠.

 

Rollouts을 이용한 Blue/Green 배포 해보기

App 생성 하기

NEW APP을 클릭하여 App을 생성하고 'EDIT AS YAML' 선택 후 아래 내용 붙여넣고 CREATE 버튼을 클릭합니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-tester-2233
spec:
  destination:
    name: ''
    namespace: anotherclass-223
    server: 'https://kubernetes.default.svc'
  source:
    # path도 잘 맞추세요!
    path: 2233/deploy/argo-rollouts
    # 싱크를 맞추기 위해 본인의 git repo url을 사용하세요.
    repoURL: 'https://github.com/k8s-1pro/kubernetes-anotherclass-sprint2.git'
    targetRevision: main
  sources: []
  project: default

배포하기

SYNC 클릭를 클릭하고 나오는 팝업차엥서 SYNCHRONIZE 클릭하세요.

 

배포 확인

트래픽 보내기을 보내 배포가 잘 되었는지 확인해 봅시다.
Active Service (32233) - 1.0.0 App 연결, Preview Service (32243) - 1.0.0 App 연결)

# Active Service
while true; do curl http://192.168.56.30:32233/version; sleep 2; echo ''; done;

# 결과
[App Version] : Api Tester v1.0.0
[App Version] : Api Tester v1.0.0

# Preview Service
while true; do curl http://192.168.56.30:32243/version; sleep 2; echo ''; done;

# 결과
[App Version] : Api Tester v1.0.0
[App Version] : Api Tester v1.0.0

ArgoCD UI에서 Blue/Green 배포 시작하기

배포 파일먼저 확인해보시죠.

 

 

▶ service-active.yaml

apiVersion: v1
kind: Service
metadata:
  name: api-tester-2233-active
  labels:
    part-of: k8s-anotherclass
    ...
spec:
  selector:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-2233
  ports:
    - port: 80
      targetPort: http
      nodePort: 32233
  type: NodePort

 

▶ rollout.yaml 설정 내용

 

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-tester-2233
  labels:
    part-of: k8s-anotherclass
     ...
spec:
  replicas: 2
  strategy:
    blueGreen:
    # 주 서비스 (버전 업그레이드시 Blue에서 Green으로 변경됨)
    activeService: api-tester-2233-active
    # 버전 업그레이드시 새로 만들어지는 ReplicaSet의 Pod에 먼저 연결되는 서비스
    previewService: api-tester-2233-preview
    # 새 ReplicaSet이 활성화되면 바로 트래픽을 전환하는지 여부
    autoPromotionEnabled: false
        ...
  template:
  metadata:
    labels:
      part-of: k8s-anotherclass
      component: backend-server
      name: api-tester
      instance: api-tester-2234
      version: 1.0.0

 

https://argo-rollouts.readthedocs.io/en/stable/features/bluegreen/

 

▶ HPA 생성시 예제

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: api-tester-2233
spec:
  maxReplicas: 4
  minReplicas: 2
  scaleTargetRef:
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    name: api-tester-2233
  targetCPUUtilizationPercentage: 80

버전업을 위해 Git에서 image의 tag 변경 (1.0.0 -> 2.0.0로 변경)

spec:
  containers:
    - envFrom:
        - configMapRef:
            name: api-tester-2233-properties
      # '1pro/api-tester:1.0.0' -> '1pro/api-tester:2.0.0' 로 변경
      image: '1pro/api-tester:2.0.0'

SYNC 맞추기

ArgoCD에서 Applications > api-tester-2233 > SYNC 클릭

트래픽 확인

아까 while문으로 2초마다 요청을 날린 화면을 참고해 봅시다.
조금 기다린후에 전환이 되었다면 잘 생성된 것입니다.

 

(Active Service (32233) - 1.0.0 App 연결, Preview Service (32243) - 2.0.0 App 연결)

 

Promote 진행

▶ ArgoCD > Applications > api-tester-2233 > Rollout > [...]클릭 > promote-Full

 

 

▶ Argo Rollouts Dashboard

http://${Master Node IP}:30003/rollouts/anotherclass-223에 접속하면 아래와 같은 Argo Rollouts대시보드 화면이 나오게 됩니다.

 

Promote와 PromoteFull두 버튼이 있는데 차이점은 다음과 같습니다.

• Promote : 다음 단계까지 진행
• Promote Full : 일시정지 무시하고 모든 단계 진행

 

 

트래픽 확인

(Preview Service (32233) - 2.0.0 App 연결, Preview Service (32243) - 2.0.0 App 연결)

 

리소스 정리하기

---

Rollouts을 이용한 Canary 아키텍처

차후 게시글에서 안내하겠지만 Deployment로 작업하는 Canary방식을 간단히 설명하자면 이렇습니다.

 

우선 Ingress Controller(Nginx, istio, 등)를 이용하여 트래픽에 분산을 주는 방식을 채택하고 분산하는 방법입니다. 그리고 차후 v2버전이 QA담당자에 의해 Pod를 사용할 수 있음을 통보받으면 v1의 Deployment, Ingress, Service를 삭제하여 모든 트래픽이 v2를 바라보게 하는 방식입니다.

 

Rollouts를 이용한 Canary방식은 트래픽에 분산을 주는 방식은 비슷합니다. 하지만 이것을 Rollouts에서 아래와 같은 속성으로 비율을 선택할 수 있는 것이죠.

 

- setWeight: 33
- pause: {}
- setWeight: 66
- pause: { duration: 2m}

 

이렇게 하면 초기 v2가 생성되면 33%의 트래픽은 v2를 바라보게되고 promote명령을 주어 다음 단계로 넘어가면 v1의 Pod를 1개를 죽이고 v2의 트래픽을 66%트래픽으로 변경합니다. 그리고 2분후에는 남은 v1의 Pod를 죽이고 모든 트래픽을 v2로 향하게 하는 방식인거죠.

 

Rollouts를 이용한 방법에서의 가장 큰 차이는 Service를 하나만 만들어 사용한다는 것입니다.

 

아래 이미지를 바탕으로 설명한 부분을 한번 더 쉽게 이해해 보시죠.

 

​

Argo Rollouts CLI 설치 (v1.6.4)

Windows

// root 계정
curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.4/kubectl-argo-rollouts-linux-amd64 
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

Mac

// root 계정
curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.4/kubectl-argo-rollouts-linux-arm64 
chmod +x ./kubectl-argo-rollouts-linux-arm64
mv ./kubectl-argo-rollouts-linux-arm64 /usr/local/bin/kubectl-argo-rollouts

설치 확인

kubectl argo rollouts version

# 결과
kubectl-argo-rollouts: v1.6.4+a312af9
  BuildDate: 2023-12-11T18:31:15Z
  GitCommit: a312af9f632b985ec13f64918b918c5dcd02a15e
  GitTreeState: clean
  GoVersion: go1.20.12
  Compiler: gc
  Platform: linux/amd64

조회하기

-w

해당 옵션은 linux의 watch 명령어라고 생각하면 된다.

# Rollout 조회 하기
kubectl argo rollouts get rollout api-tester-2233 -n anotherclass-223 -w

https://argo-rollouts.readthedocs.io/en/stable/generated/kubectl-argo-rollouts/kubectl-argo-rollouts/

Argo Rollouts를 이용한 Carary 배포 해보기

위에 설치한 cli로 해보겠습니다.
Rollouts의 경우 익숙해지면 대쉬보드보드 cli명령어가 훨씬 편해지게 됩니다....라고 합니다??

Master에서 Kubectl로 Rollouts 배포하기

꼭 해당 소스코드를 열어서 읽어보시기 바랍니다.

kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/rollout.yaml -n anotherclass-223
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/configmap.yaml -n anotherclass-223
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/secret.yaml -n anotherclass-223
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/service.yaml -n anotherclass-223

배포 모니터링

# Rollout 조회 하기
kubectl argo rollouts get rollout api-tester-2234 -n anotherclass-223 -w

트래픽 보내기 (1.0.0 App 연결)

# Service
while true; do curl http://192.168.56.30:32234/version; sleep 2; echo ''; done;

# 결과
[App Version] : Api Tester v1.0.0
[App Version] : Api Tester v1.0.0

rollout.yaml 설정 내용

ex) pause

• pause: { duration: 10 } # 10 seconds
• pause: { duration: 10s } # 10 seconds
• pause: { duration: 10m } # 10 minutes
• pause: { duration: 10h } # 10 hours

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-tester-2234
  labels:
    part-of: k8s-anotherclass
    ...
spec:
  replicas: 2
  strategy:
    canary:
      steps:
        - setWeight: 33
        - pause: {}
        - setWeight: 66
        - pause: { duration: 2m }
  selector:
    matchLabels:
        ...  # (이하 Deployment Spec과 상동)

 

https://argo-rollouts.readthedocs.io/en/stable/features/canary/

Argo Rollouts CLI로 Canary 배포 시작하기 (1.0.0 -> 2.0.0로 변경)

# kubectl argo rollouts edit <ROLLOUT_NAME> -n <NAMESPACE_NAME> 
kubectl argo rollouts edit api-tester-2234 -n anotherclass-223
# kubectl argo rollouts set image <ROLLOUT_NAME> <CONTAINER_NAME>=<IMAGE>:<TAG> -n <NAMESPACE_NAME>
kubectl argo rollouts set image api-tester-2234 api-tester-2234=1pro/api-tester:2.0.0 -n anotherclass-223

다음 단계 진행하기

Argo Rollout Dashboard에서 Detail 화면 보기에서 현재 Pause로 인해 일시정지가 된 상태로 보일겁니다.
다음 단계 진행을 위해 Promote 클릭하여 다음 단계로 진행하도록 하겠습니다.

 

대시보드가 아닌 CLI로 진행하고 싶다면 다음 명령어를 사용해도 됩니다.

 

# kubectl argo rollouts promote <ROLLOUT_NAME> -n <NAMESPACE_NAME> 
kubectl argo rollouts promote api-tester-2234 -n anotherclass-223

 

Dashboard 접속은 아래 url을 참고하세요.

 

http://${Master Node IP}:30003/rollouts/rollout/anotherclass-223/api-tester-2234

 

각 단계에 대한 설명입니다.

• Step1. Set Weight: 33% : Stable​ 2 pod, Canary 1 pod 상태로 만듬
• Step2. Pause : Promote 클릭 때까지 멈춤
• Step3. Set Weight: 66% : Stable 1 pod, Canary 2 pod 상태로 만듬
• Step4. Pause (2m) : 2분 동안 멈춤
• Step5. : Canary 2 pod 상태로 만듬

트래픽 확인 (1.0.0 App 연결, 2.0.0 App 연결)

# Service

while true; do curl http://192.168.56.30:32234/version; sleep 2; echo ''; done;

# 결과
[App Version] : Api Tester v1.0.0
[App Version] : Api Tester v1.0.0
[App Version] : Api Tester v2.0.0 # 간할적으로 v2.0.0이 나와야 합니다.

다음 단계 진행하기

대시보드를 통해 다음 단계로 진행하거나 CLI명령어를 사용해 마저 다음단계를 진행하면 완전히 Pod가v2로 전환된 것을 확인 할 수 있을겁니다.

# Service

while true; do curl http://192.168.56.30:32234/version; sleep 2; echo ''; done;

# 결과
[App Version] : Api Tester v2.0.0
[App Version] : Api Tester v2.0.0

리소스 정리하기

방금 만든 Pod들을 삭제하여 다음 테스트를 위해 깨끗하게 만들어 줍시다.

kubectl delete -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/rollout.yaml -n anotherclass-223
kubectl delete -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/configmap.yaml -n anotherclass-223
kubectl delete -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/secret.yaml -n anotherclass-223
kubectl delete -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/service.yaml -n anotherclass-223