Argo CD 및 Istio를 사용한 카나리아 배포

Argo CD의 두 번째.이번에는 이를 Istio와 결합시켜 참새 배치를 처리하는 방법을 보게 될 것이다.
Canary 배포는 응용 프로그램의 새 버전을 서버의 일부분만 배치하는 방법입니다.새 버전에 오류를 도입하면 일부 사용자에게만 영향을 줍니다.이러한 유형의 배치는 대부분의 상황에서 여러 단계로 구성되어 있으며, 이러한 절차는 모든 데이터가 카나리아 버전으로 전송되고 안정적인 버전이 될 때까지 카나리아 버전에 점점 더 많은 데이터를 전송한다.모든 절차 사이, 우리는 모든 것이 정상적임을 확보하기 위해 몇 가지 테스트를 진행할 수 있다.테스트에서 오류가 발견되면 이전 작업 버전으로 롤백합니다.이것은 모든 사용자에게 영향을 주지 않고 새 버전을 검증할 수 있다는 것을 의미한다.
이 프레젠테이션에서는 Argo CD에서 제공하는 애플리케이션을 배포합니다.이 응용 프로그램 및 코드에 대한 추가 정보here.
그것은 우리의 시범에 매우 적합하다.이는 초당 여러 개의 POST 요청을 보내는 웹 UI를 제공합니다.각 POST 요청은 하나의 풍선으로 표시됩니다.우리의 예시에서 우리는 파란색 버전으로 응용 프로그램을 배치한 다음에 참새 배치를 사용하여 주황색 버전으로 업데이트했다.다음 그림에서 데이터가 현재 버전(파란색)과 새 카나리아 버전(주황색) 사이에서 어떻게 경로화되는지 볼 수 있습니다.

요구 사항

Kubernetes 그룹

우리는 시연에서 GKE를 사용할 것이다.구글 클라우드 계정이 있다면, 다음 명령으로 간단하게 그룹을 만들 수 있습니다.만약 집단이 있다면, 다음 단계로 들어갈 수 있습니다.

gcloud beta container clusters create gke-argocd-canary \
  --release-channel regular 

Istio 회사

istioctl를 사용하여 istio를 설치할 수 있습니다.

istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled

Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Argo CD 롤업

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
https://argoproj.github.io/argo-cd/

Kubernetes를 사용하면 배포 리소스를 사용하여 애플리케이션을 관리할 수 있습니다.Argo CD 볼륨 전시회의 경우 배포 대신 볼륨 전시회 리소스를 사용합니다.배포와 유사하게 Argo CD는 Replicaset을 만들고 서비스에 POD를 식별하기 위해 탭을 추가합니다.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Istio YAML 준비

우선, 우리는 Istio 자원: 게이트웨이와 가상 서비스를 만들어야 한다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
  labels:
    app: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio-vs
  labels:
    app: istio-vs
spec:
  hosts:
  - "*"
  gateways:
  - istio-gateway
  http:
    - name: primary
      route:
        - destination:
            host: demo
          weight: 100
        - destination:
            host: demo-canary
          weight: 0

지금부터 데이터의 100%가 주 서비스로 흐를 것이다 (이곳을 프레젠테이션이라고 부른다).잠시 후 Argo CD가 이 값을 변경해서 참새 서비스에 데이터를 보내는 것을 볼 수 있습니다.

볼륨 확장 리소스 만들기

Kubernetes에 배포된 것처럼 새로운 필드가 있습니다.
다음 사항을 살펴보겠습니다.

  strategy:
    # which strategy to use (blueGreen, canary..)
    canary:
    # this part represents all the steps during an update.
      steps:
    # we send at the beginning of the new release 20% of the traffic to the canary release.
    # To do that, Argo CD will update the weight of Istio's VirtualService.
      - setWeight: 20
    # Then we wait 1min to generate some traffic on the canary release.
      - pause:
          duration: "1m"
    # After 1 min, we send 50% of the traffic to the canary release.
      - setWeight: 50
    # Then we wait again 2min
      - pause:
          duration: "2m"
    # At the end if no more step is present, 
    # Argo will send 100% of the traffic to the canary release.
      canaryService: demo-canary # represents our canary clusterIP service.
      stableService: demo # represents our main clusterIP service.
      trafficRouting:
        istio:
           virtualService: 
            name: istio-vs
            routes:
            - primary 

리소스의 전체 YAML 및 clusterIP 서비스를 제공합니다.

---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo
  labels:
    app: demo
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause:
          duration: "1m"
      - setWeight: 50
      - pause:
          duration: "2m"
      canaryService: demo-canary
      stableService: demo
      trafficRouting:
        istio:
           virtualService: 
            name: istio-vs
            routes:
            - primary 
  replicas: 4
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: demo
      version: blue
  template:
    metadata:
      labels:
        app: demo
        version: blue
    spec:
      containers:
      - name: demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - name: web
          containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "140m"
---
apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: demo
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: demo-canary
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: demo
  type: ClusterIP

애플리케이션 배포

우리는 Argo CD에 응용 프로그램을 배치하기 위해 두 개의 필수 파일이 있습니다.이렇게 해서 Argo CD에 연결하고 응용 프로그램을 배포합니다.
이 점을 어떻게 하는지에 대해서는 아무런 힌트가 없다.

실행 중인 Argo CD의 암호를 가져옵니다.

kubectl get pods \
  -n argocd \
  -l app.kubernetes.io/name=argocd-server \
  -o "jsonpath={.items[0].metadata.name}"

포트를 사용하여 액세스합니다.

kubectl port-forward svc/argocd-server -n argocd 8080:443

Argo CD에서 응용 프로그램을 만들 때 추가할 정보:



배치된 후에 우리는 응용 프로그램에 접근할 수 있다.Istio에서 사용하는 로드 밸런서 IP만 있으면 됩니다.

kubectl -n istio-system get services istio-ingressgateway \
  -o "jsonpath={.status.loadBalancer.ingress[0].ip}"

브라우저에서 이 IP에 액세스하면 다음 내용이 표시됩니다.

각 기포는 로드 밸런서 IP에 대한 POST 요청을 나타냅니다.
계속하기 전에 새로운kubectl 명령을 보여 주십시오.kubectl argo rollouts get rollout demo 볼륨 표시줄의 상태를 볼 수 있습니다.카나리아가 배치되는 동안 모든 절차가 표시됩니다.

새 버전을 배포합니다.

네, 파란색 거품이 좋아요. 하지만 오렌지색 거품을 입어보고 싶어요.두 가지 옵션이 있습니다. 첫 번째는 업데이트를 제출하는 것이고, 두 번째는kubectlcli를 사용합니다.우리는 두 번째 옵션을 사용할 것이다. 프레젠테이션에 더욱 간단하다.kubectl set image 와 유사하게 Rollow 에는 다음과 같은 등가물이 있습니다.

kubectl argo rollouts set image demo "*=argoproj/rollouts-demo:orange"

너는 이런 물건이 있어야 한다.

카나리아 배치의 진도와 현재 절차를 볼 수 있습니다.

따라서 브라우저에서 응용 프로그램으로 돌아가면 다음과 같은 내용이 표시됩니다.

몇 분 후, 데이터의 50%는 두 버전 사이에 분배된다.
완료되면 롤업 표시줄의 상태를 다시 표시할 수 있습니다.롤업은 건강하고 오렌지색 라벨은 안정적이어야 한다.

롤업 요약:

롤업 리소스는 Argo CD

의 플러그인입니다.

볼륨 표시줄 리소스만 만들고 배포는 만들지 않음

카나리아 또는 파란색 정책을 사용할 수 있습니다

지원 대상 포털: Istio, AWS ALB, Nginx, SMI

Argo CD 업데이트 자체 Istio 가상 서비스에서의 서비스 가중치

검증

우리는 새 버전에 문제가 없도록 카나리아 배치 기간에 테스트를 추가할 수 있다.그것은 명령을 실행하는 것과 같은 간단한 테스트일 수도 있고, 프로메테우스를 조회하는 것과 같은 복잡한 테스트일 수도 있다.이것이 바로 우리가 해야 할 일이다.
YAML 파일로 돌아가면 AnalysisTemplate 유형의 새 리소스를 만들어야 합니다.

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    successCondition: result[0] >= 0.95
    interval: 30s
    failureLimit: 1
    provider:
      prometheus:
        address: http://prometheus.istio-system.svc.cluster.local:9090
        query: |
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[1m]
          )) / 
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[1m]
          ))

이 테스트에서, 우리는 Istio가 설치한 Prometheus를 조회합니다.
우리는 카나리아 배치 기간에 30초마다 Prometheus를 조회하여 HTTP 요청이 마지막 분에 잘못된 비율을 확인하기를 희망합니다.결과가 5%(결과 [0]>=0.95)보다 크면 테스트가 실패했다고 간주됩니다.
따라서 5분 동안 여러 개의 테스트가 실행됩니다.만약 그 중 하나가 실패한다면, 배치는 멈추고 이전의 정상 버전으로 돌아갈 것이다.
우리의 테스트는 이미 준비가 되었으니, 우리는 그것을 우리의 작업 흐름에 추가해야 한다.처음 출시된 YAML에서 어떤 새로운 내용이 있는지 살펴보자.

---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo
  labels:
    app: demo
spec:
  strategy:
    canary:
      # New part
      analysis:
        templates:
        # name of AnalysisTemplate
        - templateName: success-rate
        # When it begins (after the 1-minute pause)
        startingStep: 2
        args:
        - name: service-name
          # name of the canary service (used in prometheus to find the correct metrics)
          value: demo-canary.default.svc.cluster.local
      steps:
      - setWeight: 20
      - pause:
          duration: "1m"
      - setWeight: 50
      - pause:
          duration: "2m"
      canaryService: demo-canary
      stableService: demo
      [....]

1분 동안 멈추면 30초마다 테스트를 실행합니다.우리는 잠시 멈춘 후에 그것을 시작합니다. 왜냐하면 우리는 약간의 데이터를 생성해야 하기 때문입니다. 그렇지 않으면 프로메테우스에서 어떤 데이터도 조회할 수 없습니다.
한번 해보자!우리는 새로운 이미지 태그를 배치하고 상태 코드가 500인 HTTP 요청을 생성해야 한다.불량 유량이 발생할 수 있는 두 가지 가능성.우리는 배치된 프로그램을 직접 사용할 수 있으며, 오류 항목으로 오류 수를 선택할 수도 있고,'나쁜'버전만 배치할 수도 있다.
오류 버전을 배포합니다.

kubectl argo rollouts set image demo "*=argoproj/rollouts-demo:bad-green"

우리는 두 가지 새로운 유형의 기포를 볼 수 있다.

녹색 = 성공적인 HTTP 요청

검은색 동그라미가 있는 녹색 = 오류 HTTP 요청

만약 우리가 이 전시를 묘사한다면 무슨 일이 일어날지 봅시다.

테스트가 두 번 실패하여 롤업 표시줄의 상태가 내려갔습니다.Argo CD가 이전 정상 버전으로 롤백되었지만 성능 저하 상태가 유지됩니다.정상적인 상태를 회복하기 위해서 우리는 수동으로 버전을 정확한 이미지로 변경해야 한다.
실패한 테스트에 대한 자세한 내용을 보려면 다음을 수행하십시오.

$ kubectl get analysisrun
NAME                STATUS
demo-588d8b6cb4-9   Failed

우리는 HTTP 요청의 77% 와 87% 만 성공했습니다.이것은 아직 충분하지 않다. 우리는 적어도 95퍼센트는 필요하다.
검증 요약:

테스트용 분석 템플릿

분석 템플릿을 여러 볼륨 모음에 연결할 수 있음

여러 분석 템플릿

을 롤오버 표시줄에서 여러 단계부터 사용할 수 있습니다.
전체 코드: https://github.com/pabardina/argocd-canary