Argo Rollouts로 프로그레시브 딜리버리: Canary/Blue-Green, 자동 프로모션·중단, 메트릭 연동(Prometheus)

Argo Rollouts로 프로그레시브 딜리버리: Canary/Blue-Green, 자동 프로모션·중단, 메트릭 연동(Prometheus)

이전 글들에서 Nginx/HAProxy, KEDA/HPA로 무중단 배포와 부하 대응을 다뤘다면, 이번에는 Kubernetes에서 Argo Rollouts로 카나리/블루그린을 자동화합니다. 배포는 “배포 → 관찰 → 승격/중단” 루프가 핵심입니다. Rollouts는 이 루프를 선언적 YAML 한 장으로 완성합니다.

---

1) 핵심 개념 요약

• Rollout: Deployment 대체 리소스(동일한 스펙 대부분 지원). strategy로 Canary/BlueGreen 지정.
• Analysis: 배포 단계마다 지표/헬스 체크를 수행해 자동 승격 또는 자동 중단.
• Traffic Routing: Nginx Ingress / ALB / Istio / SMI 등과 연동해 가중치를 조절.

# 설치(버전은 환경에 맞게)
kubectl create ns argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# 대시보드(선택)
kubectl -n argo-rollouts port-forward svc/argo-rollouts-dashboard 3100:3100

---

2) Canary 전략(가중치 전환 + 자동 분석)

2-1) 기본 Rollout 스켈레톤

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: order-api
  namespace: prod
spec:
  replicas: 4
  selector:
    matchLabels: { app: order-api }
  template:
    metadata:
      labels: { app: order-api }
    spec:
      containers:
        - name: app
          image: registry.example.com/order-api:1.2.3
          ports:
            - containerPort: 8080
  strategy:
    canary:
      canaryService: order-api-canary
      stableService: order-api-stable
      trafficRouting:
        nginx: {}   # ALB를 쓴다면 alb: {} 로 교체
      steps:
        - setWeight: 10
        - pause: {duration: 2m}
        - analysis:
            templates:
              - templateName: order-api-error-ratio
        - setWeight: 30
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: order-api-latency
        - setWeight: 60
        - pause: {duration: 5m}
        - setWeight: 100

canaryService/stableService는 동일한 DNS 이름을 유지하되, Rollouts가 엔드포인트 집합을 교체합니다. Nginx/ALB Ingress Controller는 해당 서비스 쌍을 기준으로 가중치를 반영합니다.

2-2) 서비스/인그레스(예: Nginx Ingress)

apiVersion: v1
kind: Service
metadata:
  name: order-api-stable
  namespace: prod
spec:
  selector: { app: order-api }    # Rollouts가 stable 셋으로 연결
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: order-api-canary
  namespace: prod
spec:
  selector: { app: order-api }    # canary 셋으로 연결
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-api
  namespace: prod
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    argo-rollouts.argoproj.io/managed-by-rollouts: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
        - path: /orders
          pathType: Prefix
          backend:
            service:
              name: order-api-stable
              port:
                number: 80

Ingress에 managed-by-rollouts 주석을 달면, Rollouts 컨트롤러가 Nginx에 필요한 가중치/헤더 기반 설정을 자동 주입합니다.

---

3) AnalysisTemplate: Prometheus 지표로 자동 판정

배포 단계마다 에러율/지연을 측정합니다. 임계 초과 시 즉시 중단하고 자동 롤백합니다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: order-api-error-ratio
  namespace: prod
spec:
  args:
    - name: svc
      value: "order-api"
  metrics:
    - name: http-error-ratio
      interval: 30s
      count: 10
      successCondition: result <= 0.03
      failureLimit: 1
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_server_requests_seconds_count{service="{{args.svc}}",status=~"5.."}[1m])) /
            sum(rate(http_server_requests_seconds_count{service="{{args.svc}}"}[1m]))
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: order-api-latency
  namespace: prod
spec:
  args:
    - name: svc
      value: "order-api"
  metrics:
    - name: http-latency-p95
      interval: 30s
      count: 10
      successCondition: result <= 0.8
      failureLimit: 1
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.95,
              sum by (le) (rate(http_server_requests_seconds_bucket{service="{{args.svc}}"}[1m])))

successCondition은 각 샘플의 판정식입니다. count 만큼 반복 측정해 실패가 failureLimit를 넘으면 해당 Step에서 롤아웃이 중단됩니다.

---

4) Blue-Green 전략(빠른 스위치 & 즉시 롤백)

Blue(Stable)과 Green(Preview) 두 환경을 만들어, 헬스 OK면 단번에 스위칭합니다.

spec:
  strategy:
    blueGreen:
      activeService: order-api-stable
      previewService: order-api-preview
      autoPromotionEnabled: true         # 자동 승격
      autoPromotionSeconds: 60           # 대기 후 승격
      scaleDownDelaySeconds: 300         # 롤백 대비 구버전 유지 시간

카나리는 “점진”, 블루그린은 “즉시” 전환에 유리합니다. 팀/릴리즈 위험도에 따라 전략을 선택하세요.

---

5) 헤더/쿠키 기반 트래픽 분기(내부 QA/Canary 고정)

strategy:
  canary:
    trafficRouting:
      nginx:
        stableIngress: order-api
        additionalIngressAnnotations:
          nginx.ingress.kubernetes.io/canary-by-header: "X-CANARY"
          nginx.ingress.kubernetes.io/canary-by-header-value: "1"
    steps:
      - setWeight: 0   # 일반 사용자 0%, 헤더 사용자만 카나리
      - pause: {duration: 10m}

내부 QA나 특정 고객만 새 버전을 보게 하여 리스크를 더 줄일 수 있습니다.

---

6) 운영 워크플로우(복붙용)

1. 이미지 태깅: :1.2.3 빌드/푸시
2. Rollout 업데이트: image: ...:1.2.3로 패치
3. 진행 확인: kubectl argo rollouts get rollout order-api -n prod --watch
4. 중단/재개: 실패 시 abort, 원인 해결 후 promote/retry

# CLI 설치(선택)
curl -sLO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

---

7) 관찰성 연동(Tempo/Loki 링크)

• Prometheus: 에러율/지연으로 Analysis 판정
• Tempo: 실패 Step 시간대의 트레이스로 병목 확인
• Loki: 같은 시간대의 trace_id로 상세 로그 열람

Grafana 대시보드에 “최근 배포” 변수(이미지 태그, Rollout Step)를 노출해 지표/로그/트레이스를 한 화면으로 묶으면 원인 파악 속도가 크게 빨라집니다.

---

8) 자주 겪는 함정과 해결

• 가중치가 안 바뀜: Ingress Controller가 지원 버전인지, managed-by-rollouts 주석이 있는지 확인.
• Analysis 실패 남발: 지표 윈도우를 1m→3m로 늘리고, failureLimit를 2로 상향.
• 롤백 늦음: Blue-Green에서 scaleDownDelaySeconds를 넉넉히(5~10분) 두고 즉시 되돌리기.
• 세션 유실: 스티키 세션 필요 시 Ingress 주석/외부 세션 저장소(예: Redis) 사용.

---

9) 보안·권한

• Rollouts 컨트롤러에 필요한 RBAC 권한이 있는지(서비스/인그레스 패치 권한 포함).
• 프로덕션/스테이징 네임스페이스 분리, 승격 승인을 GitOps PR 머지로 제한(Argo CD 연계 추천).

---

10) 체크리스트(복붙용)

• Argo Rollouts 설치 및 대시보드 접근 확인
• Rollout + stable/canary Service + Ingress 구성
• Prometheus 연결(에러율/지연 쿼리 점검), AnalysisTemplate 적용
• 카나리 단계: 10% → 30% → 60% → 100% 스텝 + pause 시간 정의
• 헤더/쿠키 기반 내부 검증(옵션), 실패 시 자동 중단/롤백 확인
• Grafana: “최근 배포” 변수, Tempo/Loki 링크 구성

정리하면, Rollouts는 배포-관찰-승격 루프를 선언적으로 고정해 줍니다. 카나리/블루그린, 지표 기반 자동 판정, 즉시 롤백까지 하나의 파이프라인에 녹여 팀의 릴리스 자신감을 크게 올려보세요.