Istio + Argo Rollouts로 구성하는 카나리 배포: 파드 메트릭 격리부터 헤더 기반 테스트 라우팅까지

                     ┌────────────────────────────────────┐
  일반 요청 ─────────▶│       Istio Ingress Gateway         │
  X-Canary: true ───▶│          (Envoy Proxy)              │
                     └─────────────┬──────────────────────┘
                                   │ VirtualService
                           ┌───────┴─────────┐
                    weight │ 90%             │ 10% (또는 헤더 매칭)
                           ▼                 ▼
              ┌─────────────────┐   ┌─────────────────┐
              │  Stable Service │   │  Canary Service │
              └────────┬────────┘   └────────┬────────┘
                       │                     │
                       ▼                     ▼
              ┌─────────────────┐   ┌─────────────────┐
              │   Stable Pods   │   │   Canary Pods   │
              │ [Envoy Sidecar] │   │ [Envoy Sidecar] │
              └────────┬────────┘   └────────┬────────┘
                       │  메트릭              │  메트릭
                       └──────────┬──────────┘
                                  ▼
                           ┌────────────┐
                           │ Prometheus │◀── AnalysisTemplate 쿼리
                           └────────────┘
                                  ▲
                    ┌─────────────┴───────────────┐
                    │  Argo Rollouts Controller    │
                    │ (자동 프로모션 / 롤백 판단)   │
                    └─────────────────────────────┘

# 카나리 워크로드에 도달한 요청만 필터링
istio_requests_total{destination_workload="my-service-canary"}

# 사전 준비: stable과 canary를 위한 별도 Service 생성
apiVersion: v1
kind: Service
metadata:
  name: my-service-stable
spec:
  selector:
    app: my-service
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service-canary
spec:
  selector:
    app: my-service
  ports:
    - port: 80
      targetPort: 8080

# DestinationRule — stable/canary 서브셋 정의
# rollouts-pod-template-hash 값은 Argo Rollouts가 자동으로 관리하므로
# 수동으로 해시값을 채우거나 편집할 필요가 없습니다
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service
  subsets:
    - name: stable
      labels:
        rollouts-pod-template-hash: stable   # Rollouts가 실제 해시값으로 자동 패치
    - name: canary
      labels:
        rollouts-pod-template-hash: canary   # Rollouts가 실제 해시값으로 자동 패치

# VirtualService — Argo Rollouts가 배포 단계마다 weight 값을 자동 수정
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
    - my-service                  # spec.hosts는 필수 필드
  http:
    - name: primary
      route:
        - destination:
            host: my-service
            subset: stable
          weight: 100
        - destination:
            host: my-service
            subset: canary
          weight: 0

# Rollout — 카나리 단계, 트래픽 라우팅, 분석 연결 (전략 부분 발췌)
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service
spec:
  # selector, replicas, template 등 기본 필드는 Deployment와 동일한 형태로 작성
  strategy:
    canary:
      stableService: my-service-stable    # 앞서 생성한 Service 참조
      canaryService: my-service-canary    # 앞서 생성한 Service 참조
      trafficRouting:
        istio:
          virtualService:
            name: my-service-vs
            routes:
              - primary
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: canary-workload
                value: my-service-canary
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100

# AnalysisTemplate — 카나리 파드에 도달한 요청의 성공률만 측정
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: canary-workload
  metrics:
    - name: success-rate
      interval: 1m
      successCondition: result[0] >= 0.95
      failureLimit: 3    # 누적 3회 실패 시 롤백 (연속 실패 기준은 consecutiveErrorLimit 사용)
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            (
              sum(rate(istio_requests_total{
                destination_workload="{{args.canary-workload}}",
                reporter="destination",
                response_code!~"5.*"
              }[2m]))
              /
              sum(rate(istio_requests_total{
                destination_workload="{{args.canary-workload}}",
                reporter="destination"
              }[2m]))
            ) or on() vector(1)

# Rollout steps — 헤더 라우트 먼저 설정하고, 검증 후 가중치 트래픽 시작
steps:
  - setHeaderRoute:
      name: canary-header-route
      match:
        - headerName: X-Canary
          headerValue:
            exact: "true"
  - pause: {}              # QA가 헤더로 카나리 테스트, 수동 승인 대기
  - setWeight: 10          # 헤더 라우트 유지한 채 일반 트래픽 10%도 카나리로
  - pause: {duration: 10m}
  - analysis:
      templates:
        - templateName: success-rate
      args:
        - name: canary-workload
          value: my-service-canary
  - setWeight: 50
  - pause: {duration: 10m}
  - setHeaderRoute:
      name: canary-header-route    # match 없이 같은 이름 → 해당 헤더 라우트 삭제
  - setWeight: 100

# QA 팀 — X-Canary 헤더를 붙여 카나리 파드로 직접 요청
curl -H "X-Canary: true" https://my-service.example.com/api/health
 
# 일반 사용자 — 헤더 없이 → stable 파드로 라우팅
curl https://my-service.example.com/api/health

# 카나리 파드의 P99 응답 시간 (히스토그램 버킷 기반)
histogram_quantile(0.99,
  sum(rate(istio_request_duration_milliseconds_bucket{
    destination_workload="my-service-canary",
    reporter="destination"
  }[5m])) by (le)
)

# 카나리 파드가 보낸 요청 중 5xx 발생율 (카나리→의존 서비스 영향 측정)
(
  sum(rate(istio_requests_total{
    source_workload="my-service-canary",
    response_code=~"5.*"
  }[2m]))
  /
  sum(rate(istio_requests_total{
    source_workload="my-service-canary"
  }[2m]))
) or on() vector(0)