개요

간단하게 트래픽을 조건에 따라 라우팅해봤으니 이제 비율에 따라 라우팅을 해보자.
아울러 트래픽 분산을 한다면 또 빠질 수 없는 내용 중 하나가 배포 전략이다.
이와 관련된 툴을 두 가지 활용해보자.

사전 지식

이번에는 실습에는 flagger와 argo rollouts를 사용할 것이다.
이중에서 argo rollouts는 조금 미리 정리를 하고 실습에 들어간다.

argo rollouts란?

쿠버네티스의 디플로이먼트 업데이트 전략을 훨씬 확장시키는 애드온.
디플로이먼트의 업데이트 전략은 정말 구리다.
실질적으로 간단하게 할 수 있는 것은 롤링 업데이트 뿐이고, 블루그린, 카나리 등의 방법을 사용하기 위해서는 직접 커스텀하는 수밖에 없는데 이걸 도와주는 것이 바로 아르고 롤아웃.

구체적으로 다음의 기능들을 가진다.

• 블루그린, 카나리 등의 다양한 배포 전략
• 위 전략들에 기반한 점진적 배포(Progressive Delivery)
• 배포를 진행하며 메트릭 기반, 혹은 명령어 설정 등을 통해 분석(Analysis) 기능 제공
• 인그레스나 서비스 메시와도 결합 가능.
• 관측 가능성 기반으로도 동작!

레플리카셋을 관리한다는 점에서는 디플로이먼트와 같기 때문에, 정말 디플의 확장처럼 생각할 만한 애드온이라고 생각한다.

아키텍처

아르고 롤아웃 컨트롤러가 있고, 이 친구가 아르고 롤아웃 관련 CRD를 추적하며 레플리카셋을 건드린다.
근데 여기에 트래픽 라우팅, 메트릭 기반 점진적 배포 등 다양하게 건드릴 수 있게 해줄 뿐인 것이다.
그래서 근본 동작 방식도 디플로이먼트와 크게 다를 게 없다.
업데이트를 해야 하는 상황이 생기면 일단 새로운 레플리카셋을 만든다.
그리고 일반 디플로이먼트로는 할 수 없는, 블루그린이나 카나리를 해주는 것이다.

여기에 추가적으로 위에서 잠시 말한 Analysis를 중간에 끼어서 진행하는 것이 가능하다.

동작 방식

업그레이드를 한다는 것은 결국 레플리카셋을 새로 만든다는 것과 같다.
이때 레플리카셋은 각자 고유한 pod-template-hash 값이 있는데, 기본적으로 아르고 롤아웃은 이 값을 활용한다.
구체적으로 자신의 파드로 트래픽을 보내는 서비스의 라벨 셀렉터에 해시 값을 추가시켜 명확하게 트래픽을 관리한다.

블루 그린 동작

먼저 블루와 그린 각각의 서비스를 두고, 처음에는 둘다 블루 버전을 가리키도록 세팅된다.
업데이트가 시작되어도 그린이 준비 상태가 되기 전까지 명확하게 블루로만 트래픽이 전달되도록 한다.
그린이 준비 상태가 됐을 때는 바로 서비스의 라벨에 해시 값을 딸깍 바꿔 트래픽을 바꿔준다.
이후에는 천천히 블루 워크로드를 스케일 다운하는 절차를 거친다.
이때 천천히 스케일 다운하는 이유는 서비스의 셀렉터를 바꿈으로 인해 일어나는 엔드포인트슬라이스 업데이트 속도 때문이다.
kube-proxy#프록시 모드에 나오듯 결국 서비스는 노드의 iptables로 (흔히) 관리되는데 이게 업데이트에 속도가 조금 걸릴 수 있기에 이때 발생할 에러를 방지하려는 것이다.

카나리 동작

카나리 동작도 마찬가지로 이전 버전(stable)과 새 버전(canary)을 가리키는 서비스를 각각 둔다.
그리고 배포가 진행되는 동안 여러 단계를 밟으면서 각 레플리카의 개수를 늘리거나 줄이는가 하면 아예 각 버전으로 흐르는 트래픽의 양을 조절하는 등의 작업을 한다.
카나리 역시 마찬가지로 배포가 끝나면 이전 버전을 천천히 스케일 다운한다.

실습 진행

이전 실습에 이어서 진행한다.

기본 가중치 분산 방법

이전에는 조건 기반 매칭으로 트래픽을 라우팅하는 다크 런치 전략을 활용했지만, 이번에는 아예 가중치를 둔다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
  - mesh
  http:
  - route:
    - destination:
        host: catalog
        subset: version-v1
      weight: 90
    - destination:
        host: catalog
        subset: version-v2
      weight: 10 

일단 가중치를 분배하는 방법은 간단하게 그냥 weight 필드를 두면 된다.
참고로 weight 필드는 합이 100이 되도록 해주는 게 좋다.

istioctl pc route webapp-7c96945758-pf498 --name 80 -ojson

가중치 설정은 라우팅 설정에 그대로 반영된다.

플래거 활용

이번엔 점진적 배포를 도와주는 툴인 플래거를 활용해본다.
플래거는 GitOps툴인 Flux의 하위 프로젝트로서 출발한 점진적 배포 툴이다.
이 녀석의 특징은 실습을 하면서 보자.

catalog 서비스에 대해 카나리 배포를 적용할 것이다.

kubectl delete virtualservice catalog -n istioinaction
kubectl delete deploy catalog-v2 -n istioinaction
kubectl delete service catalog -n istioinaction
kubectl delete destinationrule catalog -n istioinaction

활용해보기에 앞서 이미 설정돼 있던 리소스는 제거한다.
버전 업그레이드를 해볼 거니까 v2를 없애는 건 당연한데, 잘 보면 버츄얼 서비스, 서비스 등도 없애는 것을 볼 수 있다.

kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
helm repo add flagger https://flagger.app 
helm install flagger flagger/flagger \
	--namespace=istio-system \
	--set crd.create=false \
	--set meshProvider=istio \
	--set metricServer=http://prometheus:9090

간단하게 헬름을 이용해 설치를 진행한다.

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: catalog-release
  namespace: istioinaction
spec:  
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog  
  progressDeadlineSeconds: 60
  # Service / VirtualService Config
  service:
    name: catalog
    port: 80
    targetPort: 3000    
    gateways:
    - mesh    
    hosts:
    - catalog
  analysis:
    interval: 45s
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    match: 
    - sourceLabels:
        app: webapp
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 30s

그 다음 플래거의 카나리 리소스를 만든다.
먼저 타겟으로 현재 존재하는 디플로이먼트를 잡고, 트래픽을 설정하는 버츄얼 서비스도 명시한다.
본격적인 카나리 작업은 analysis를 통해 이뤄지는데, 여기에서 배포 간 기준으로 활용할 메트릭 정보도 지정한다.
위의 설정을 간단하게 설명하자면,

• 45초마다 각 단계를 진행하며, 카나리 버전으로 향하는 트래픽을 10%씩 늘린다.
  • 50%에 도달하면 작업은 완료되고 완전히 카나리로 트래픽이 옮겨진다.
• 각 단계는 이 조건을 만족해야 한다.
  • 성공률 메트릭의 경우 1분 동안의 성공률이 99% 이상이어야 한다. 또한 P99(상위 99%) 요청 시간은 500ms까지 허용한다.
  • 연속으로 5회를 불충족 시 실패로 간주하고 롤백한다.

sum(
    rate(
        istio_requests_total{
          reporter="destination",
          destination_workload_namespace=~"{{ namespace }}",
          destination_workload=~"{{ target }}",
          response_code!~"5.*"
        }[{{ interval }}]
    )
)
/
sum(
    rate(
        istio_requests_total{
          reporter="destination",
          destination_workload_namespace=~"{{ namespace }}",
          destination_workload=~"{{ target }}"
        }[{{ interval }}]
    )
)

참고로 위 메트릭들은 플래거에서 사전 정의된 템플릿이다.^[1]
커스텀 메트릭을 쓰고 싶다면 플래거 메트릭 템플릿 리소스를 만들어서 사용해야 한다.

카나리 리소스를 배포하면 신기한 모습을 볼 수 있다.
기존에 만들어뒀던 catalog의 복제본으로 primary라는 디플로이먼트를 만들고는 내 catalog의 레플리카를 0으로 만들어버린 것이다!

정말로 파드 자체가 새로 기동되는 거라 갑자기 도입하게 된다면 기가 맥히고 코가 맥히는 상황이 나올 수도 있으니 주의가 필요하다.

만들어진 primary 디플로이먼트의 스펙은 크게 다를 건 없다.
다만 라벨이랑 소유자 정보가 조금 다를 뿐이다.

서비스를 보면, 세 개가 만들어지는데 이때 canary 서비스는 테스팅 용도이고 실제로 사용되는 것은 기본 서비스와 primary이다.^[2]

그래서 기본 서비스를 보면 소유자가 플래거로 돼있고, primary 디플로이먼트를 바라보게 돼있다.

아무튼 카나리 리소스를 만들면 알아서 설정된 대로 버츄얼 서비스도 만들어주는데, 가중치를 기반으로 라우팅을 하는 것이 보인다.

데룰도 직접 만들어버린다.
이렇게 죄다 직접 만들어버리기 때문에 실습을 진행하기 이전에 삭제를 진행한 것이다.

primary 서비스가 만들어지고, 여기에 대한 데룰과 버서가 전부 만들어진 것이 표시된다.

카나리 배포

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  metrics:
  - overrides:
    - disabled: false
      match:
        metric: ALL_METRICS
        mode: SERVER
  tracing:
  - providers:
    - name: jaeger

현재 내 세팅을 따라온다면 한 가지 설정을 해줘야 하는 부분이 있다.
이전 실습에서 키알리의 에러율을 정확하게 관측하기 위해 서버에서 발생하는 메트릭을 차단했는데, 플래거의 메트릭은 이 정보를 활용하기 때문에 다시 활성화를 해줘야 한다.

이스티오 리퀘 토탈 메트릭에서 reporter destination에 대해 메트릭이 나와야 정상적으로 플래거의 빌트인 메트릭이 계산된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: catalog
    version: v1
  name: catalog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: catalog
      version: v1
  template:
    metadata:
      labels:
        app: catalog
        version: v1
    spec:
      containers:
      - env:
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: SHOW_IMAGE
          value: "true"
        image: istioinaction/catalog:latest
        imagePullPolicy: IfNotPresent
        name: catalog
        ports:
        - containerPort: 3000
          name: http
          protocol: TCP
        securityContext:
          privileged: false

플레거를 사용하게 되면 기본적으로 트래픽을 감당하는 워크로드는 primary가 된다.
primary는 기존 워크로드의 복제본으로서 생성되고 이후 버전 업그레이드에서도 마찬가지이다.
사용자는 원본에 대한 수정을 가하면 되는데, 이제 여기에서 원본은 카나리 버전을 의미하게 된다.
그래서 기존 디플로이먼트에 템플릿 필드에서 환경 변수 부분을 살짝 수정한다.

기다리다보면 조금씩 명시된 방식으로 조금씩 트래픽을 카나리쪽으로 돌리는 것을 볼 수 있다.

while true; do kubectl get vs -n istioinaction catalog -ojsonpath='{.spec.http[0].route}' | jq; sleep 10s; echo; done

버츄얼 서비스의 가중치가 어떻게 변화하는지도 살펴본다.
45초마다 카나리 스텝이 진행되기에 널널하게 10초로 잡았다.

플래거의 로그와 카나리 리소스의 상태 변화, 그리고 버츄얼 서비스의 가중치 변화를 살펴본다.

키알리로 봤을 때도 조금씩 변화가 생기는 것을 볼 수 있다.

50퍼가 되자 프로모션이 끝나고, 모든 트래픽이 카나리로 전환된다.

완전히 끝나고 나면, 카나리는 온데간데 없고 다시 primary가 100퍼센트로 표시된다.

카나리 작업이 성공하면 primary 디플로이먼트의 버전 업데이트가 진행된다.
그리고 업데이트가 완료되어 primary가 새 버전으로서 완전히 배포된다면 플래거는 다시 모든 트래픽을 primary로 돌린다.
그래서 이후로도 안정되게 트래픽을 감당하는 워크로드는 primary인 채로 있을 수 있다.
이후 카나리로 사용됐던 기존의 일반 워크로드는 다시 스케일이 0으로 줄어든다.

참고 - 실패한 방법

이건 처음에 텔레메트리 리소스 세팅을 하지 않고 진행했을 때 일어난 상황이다.

계속 에러가 발생했다.

이전에 에러율을 정확히 관측하기 위해 업스트림 측 메트릭을 없애서 그런지, 제대로 메트릭이 나오지 않는 모양이다.
근데 한번 fail난 이후로 뭔 짓을 해도 복구가 안 되는 것 같다;;
그래서 일단 카나리 리소스 자체를 또 다시 삭제하고 다시 만들었다.

그런데 다시 세팅하면서 또 문제가 발생한 것이, 기존 서비스로도 트래픽이 라우팅되는 상황이 포착됐다.

그러나 webapp의 라우팅 설정 상으로는 primary로만 트래픽이 가는 것으로 나와야 정상이다.
어떤 식으로 요청이 가는지 확인해보려고 엔보이 로그를 다시 설정하는 텔레메트리를 만들자 갑자기 문제가 해결됐다.
네트워크 투명성 어디.. 누구를 위한 투명성..

아르고 롤아웃 활용

helm repo add argo-helm https://argoproj.github.io/argo-helm
helm install argo-rollouts argo-helm/argo-rollouts --version 2.39.3 \
  --namespace=argo-rollouts --create-namespace=true

이번에는 아르고 롤아웃을 이용해본다.
아르고 롤아웃을 이스티오와, 그리고 메트릭 수집 도구와 연동하여 활용하기 위해서 다음의 작업을 해야 한다.

• 트래픽 관리 제공자 세팅
  • 동서 트래픽 케이스이므로 부분집합 레벨에서 세팅을 진행한다.
  • 이를 위해 각 부분집합과, 버츄얼 서비스에 이름을 지정한다.
  • (사실 이건 거의 다 돼있긴 하다.)
• AnalysysTemplate 리소스 생성
  • 플래거에서는 사전 정의된 템플릿이 있었으나 아르고 롤아웃에는 없다.
  • 그래서 이를 위한 리소스를 만들어야 한다.
• Rollout 리소스 생성
  • 아르고 롤아웃은 Rollout이라는 디플로이먼트의 상위호환격 리소스를 사용한다.
  • 그래서 기존 디플로이먼트에서 마이그레이션하는 작업이 필요하다.^[3]

트래픽 관리 제공자 세팅

일단 첫번째는 간단하게 해낼 수 있다.

데스티네이션 룰에서 같은 대상을 바라보는 서브셋들을 만들고 이름은 자유롭게 붙여준다.
어차피 아르고 롤아웃이 버전 별 고유 라벨을 라벨에 추가 조작을 해줄 거라 여기까지만 하면 된다.

버츄얼 서비스에서는 가중치 설정과, 위에서 세팅한 부분집합 이름을 넣어준다.
추가적으로 안전하게 라우트의 이름도 지정해주었다.

AnalysisTemplate 리소스 생성

다음으로 해줄 것은 프로메테우스 메트릭 설정이다.
참고로 프로메테우스는 이스티오 기본 실습에서 계속 설치돼있는 상태이다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 5m
    successCondition: result[0] >= 0.95
    failureLimit: 3
	count: 5
    provider:
      prometheus:
        address: http://prometheus.istio-system:9090
        query: |
	        sum(
			    rate(
			        istio_requests_total{
			          reporter="destination",
			          destination_workload_namespace=~"istioinaction",
			          destination_workload=~"canary",
			          response_code!~"5.*"
			        }[5m]
			    )
			)
			/
			sum(
			    rate(
			        istio_requests_total{
			          reporter="destination",
			          destination_workload_namespace=~"istioinaction",
			          destination_workload=~"canary",
			        }[5m]
			    )
			)

위에서 본 플래거의 기본 메트릭과 똑같이 세팅했다.

k argo rollouts create -f anal-template.yaml

아르고 롤아웃에서 제공하는 kubectl 플러그인을 이용해 넣었다.
사실 그냥 kubectl apply를 해도 상관은 없지만, 그래도 이 플러그인을 사용하면 조금 더 시각화나 설정을 편리하게 할 수 있다.

롤아웃 리소스 생성

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary
spec:
  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService:
            name: catalog
            routes:
            - catalog
          destinationRule:
            name: catalog
            canarySubsetName: canary 
            stableSubsetName: stable  
      steps:
        - setWeight: 10 # 새 버전을 10퍼센트로 맞춘다.
        - pause:
            duration: 30s
        - setWeight: 20
        - pause: {}
        - analysis:
            templates:
            - templateName: success-rate
        - pause: {}
  replicas: 5
  selector:
    matchLabels:
      app: catalog
  template:
    metadata:
      labels:
        app: catalog
        version: v1
    spec:
      containers:
      - env:
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: istioinaction/catalog:latest
        name: catalog
        ports:
        - containerPort: 3000
          name: http
          protocol: TCP
      securityContext: {}
      serviceAccountName: catalog

마지막으로 롤아웃 리소스를 만든다.
보통 롤아웃을 바로 만드는 게 보통이지만, 기존에 존재하던 워크로드를 가져와서 양식으로 옮기는 것도 가능하다.
원래는 기존 워크로드를 가져오는 실습을 했었는데, 도중에 다른 이슈 해결하다가 조금 더 간편하게 세팅하기 위해 새로 워크로드를 만들었다.
작성 방식은 strategey 필드만 제외하면 그냥 일반 디플로이먼트와 다를 게 없다.

간단하게 스텝 흐름을 보자면,

• 카나리 버전의 레플리카를 10퍼센트로 올리고 30초를 기다린다.
• 카나리 버전의 레플리카를 20퍼센트로 올리고 대기한다.
• 사용자가 수동으로 진행 지시를 하면 메트릭 측정이 이뤄진다.
• 이후 사용자의 수동 진행 지시를 대기한다.

k argo rollouts get rollout canary

성공적으로 기존 catalog의 스펙을 가져온 것이 보인다.

k argo rollouts dashboard 

아르고 롤아웃의 큰 장점 중 하나가 시각적으로 확인하기 편하다는 것이다.

카나리 버전과 스테이블 버전을 지정하기 위한 데스티네이션 룰의 부분 집합에는 알아서 template-hash 값이 들어간다.

이 값은 rollout 리소스의 status 부분에서도 찾아볼 수 있다.

카나리 배포

플래거에서 했듯이 환경 변수만 조금 수정해준다.
이때 버전을 조금 명확히 하고 싶어 파드 라벨도 수정해줬다.

이전과 동일하게 디플로이먼트에서 환경변수 값만 수정하면 본격적으로 카나리 스텝이 시작된다.

키알리로도 조금씩 파드 개수가 늘어나는 것을 확인할 수 있다.

그런데 아쉬운 점이, 키알리에서는 레플리카셋으로 버전을 구분하는 것을 시각적으로 잘 지원하지 않는다.
이걸 해결하려고 삽질을 좀 했는데, 해당 내용은 아래에 담겠다.

일단 수동으로 다음 단계를 진행시키자, 곧 메트릭 분석이 진행됐다.
처음에는 자료형을 실수해서 분석에 실패했고, 롤백이 진행됐다.

마지막으로 수동 조작을 하고, 이전 버전은 30초 뒤에 사라진다.

결론

먼저 두 툴의 동작 방식의 차이는 이 정도가 있겠다.

• 플래거
  • 디플로이먼트를 그대로 사용하면서 이를 관리하는 카나리 리소스를 둔다.
  • 원본 디플로이먼트를 새 버전을 업데이트 하는 용도로 사용하고, primary라는 복제 디플로이먼트를 운용한다.
• 아르고 롤아웃
  • 롤아웃이라는 디플로이먼트를 대체하는 새로운 리소스를 둔다.
  • 서비스(이스티오에서는 데스티네이션 룰로도 가능)에 레플리카셋의 라벨을 달아 각 버전으로 트래픽이 제대로 갈 수 있도록 만든다.

근본적인 차이는 이런데, 추가적으로 롤아웃의 경우 다양한 시스템들과 결합이 가능하고 시각화가 뛰어나다는 것이 장점이라고 생각한다.
여기에 훨씬 정교하게 조작을 하는 것이 가능하다는 것 역시 큰 장점이라 할 수 있겠다.
플래거는 간단하게 사용하기에는 좋은 편이다.
하지만 상황 모니터링이나 중간에 마음대로 배포 작업을 중지하거나 다루는 상세 설정을 할 때, 아르고 롤아웃이 더 매력적인 선택지가 된다고 본다.
다만 현재 시각화 관련으로 조금의 이슈가 있는 바, 새로 도입을 하는 조직 입장에서는 이 부분도 조금은 고려해야 할 것 같다.

번외 - 아르고 롤아웃 키알리 이슈

키알리에서 아르고 롤아웃의 왜 버전을 제대로 추적해주지 않는 걸까?
이대로라면 둘을 같이 쓰는 데 큰 아쉬움이 있다.
조금 찾아봤는데, 키알리는 역시 레플리카셋을 기준으로 버전을 구분짓지 않기 때문에 생기는 문제인 것으로 보인다.^[4]

버전 정보가 분명 프로메테우스 라벨로 들어가고는 있다.

3년 전에 이 이슈에 대한 코드 수정이 있었던 것이 확인된다.^[5]
이 당시 버전이 뭔지는 잘 모르겠다.

그러나 현재 내가 사용하는 키알리는 2.5.0인데, 이 버전은 올해 2월달에 릴리즈됐다.

그렇다면 이 이슈는 해결된 상태의 코드가 들어있을 가능성이 높지 않나..?

워크로드 탭에서 각 타입을 레플리카셋으로 구분한다는 것은 제대로 동작하고 있다는 뜻이다.

조금 더 문제를 깊게 파보자.
일단 애플리케이션으로서 catalog는 추적된다.

그러나 각 워크로드로 봤을 때는, 이것이 제대로 확인되지 않는다.

업데이트가 완료된 이후에 v3로 제대로 표시가 되고 있다.
레플리카셋 별 다른 버전을 추적하지 못하는 이슈에는 이 둘의 메트릭을 구분해서 수집하지 못한다는 것에 있는 것으로 생각된다.

위에 나온 내용으로 나는 키알리 단에서의 문제가 해결된 것이라 추측하고 있었는데, 다시 보니 최근에도 비슷한 이슈 제보가 있다.^[6]
제보자는 나와 다르게 기본적인 방식으로 두 서비스를 이용해서 카나리 롤아웃을 하는 방식을 택했는데, 실제 워크로드로 나오는 포인트는 하나라는 점에서 내가 가진 이슈와 동일하다고 할 수 있다.

이전 글, 다음 글

• 3W - 버츄얼 서비스를 활용한 기본 트래픽 관리: 7
• 3W - 트래픽 미러링 패킷 캡쳐: 9

다른 글 보기

관련 문서

참고