Argo Rollouts는 쿠버네티스에서 카나리·블루그린 배포를 Deployment 대신 관리하는 컨트롤러다. 핵심은 자동 분석(analysis)이다. 트래픽을 새 버전에 조금씩 흘리면서 에러율·지연 같은 지표를 Prometheus에 물어보고, 나쁘면 사람 손 없이 스스로 롤백한다. 점진적 배포(progressive delivery)를 "감으로 지켜보기"에서 "지표로 자동 판정"으로 바꾸는 도구다.
수동 카나리를 해 본 사람은 안다. 10%로 올리고 그라파나 앞에서 커피 식혀 가며 노려보다가, 괜찮은 것 같아 50%로 올리고, 또 노려보고… 새벽 배포엔 이게 안 된다. Argo Rollouts는 그 노려보는 일을 규칙으로 대신 시킨다.
Rollout 리소스의 골격
Deployment를 Rollout으로 바꾸고, strategy.canary 아래에 단계(step)를 적는다. 각 단계에서 트래픽 비중을 올리고, 중간에 분석을 끼운다.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: { name: checkout }
spec:
replicas: 6
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 2m }
- analysis:
templates: [{ templateName: success-rate }]
- setWeight: 50
- pause: { duration: 5m }
- setWeight: 100
selector: { matchLabels: { app: checkout } }
template: { } # 평소의 Pod 스펙AnalysisTemplate — 자동 판정의 심장
여기서 "성공"의 정의를 지표로 못 박는다. Prometheus에 성공률을 질의해서, 기준(예: 99%) 아래로 떨어지면 실패로 본다. failureLimit번 실패하면 롤아웃이 중단되고 자동으로 이전 버전으로 되돌아간다.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata: { name: success-rate }
spec:
metrics:
- name: success-rate
interval: 30s
count: 5
successCondition: result[0] >= 0.99
failureLimit: 2
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{app="checkout",code!~"5.."}[1m]))
/
sum(rate(http_requests_total{app="checkout"}[1m]))이 쿼리가 카나리 파드의 5xx 비율을 실시간으로 재고, 성공률이 99% 밑으로 두 번 떨어지면 배포를 죽인다. 사람이 자는 사이에도. 개인적으로 이 successCondition 한 줄이 Argo Rollouts를 쓰는 진짜 이유라고 본다.
트래픽을 정말로 나누려면
흔한 착각. setWeight: 10만 적으면 트래픽이 자동으로 10%만 간다고 생각하는데, 그렇지 않다. 기본 방식은 파드 개수 비율로 근사할 뿐이라 정밀하지 않다. 정확한 가중치 라우팅을 하려면 트래픽 관리자를 연결해야 한다. 서비스 메시(Istio, Linkerd)나 인그레스(NGINX, Gateway API)를 붙이면 진짜 10% 가중치가 실현된다.
| 전략 | 특징 | 비용/리스크 |
|---|---|---|
| 롤링 | 기본, 점진 교체 | 문제 시 이미 다수 노출 |
| 블루그린 | 전환 즉시·롤백 빠름 | 2배 자원 필요 |
| 카나리+분석 | 지표로 자동 판정 | 트래픽 관리자·지표 필요 |
도입 순서 추천
처음부터 완전 자동을 노리지 말자. 나는 이렇게 밟는다. 1단계, 분석 없이 pause로 수동 승인 카나리만. 손에 익힌다. 2단계, 읽기 전용으로 분석을 붙여 결과만 관찰(실패해도 롤백 안 함). 지표와 임계값을 신뢰할 수 있는지 본다. 3단계, 그제야 failureLimit을 걸어 자동 롤백을 활성화한다. 지표를 못 믿는 상태에서 자동 롤백을 켜면, 멀쩡한 배포가 밤마다 롤백되는 지옥을 본다.
자주 묻는 질문
기존 Deployment를 그대로 두고 쓸 수 있나요?
리소스 종류를 Deployment에서 Rollout으로 바꿔야 합니다. 다만 workloadRef로 기존 Deployment를 참조하게 하는 방식도 있어, 마이그레이션 부담을 줄일 수 있습니다. Pod 템플릿 자체는 거의 그대로 재사용됩니다.
분석에 꼭 Prometheus가 필요한가요?
아닙니다. Prometheus 외에 Datadog, New Relic, CloudWatch, Wavefront, 그리고 임의 Job이나 웹 요청 결과로도 판정할 수 있습니다. 요지는 "성공을 숫자로 정의할 수 있는가"이며, 그 숫자의 출처는 자유롭습니다.
카나리가 실패하면 어떻게 되나요?
failureLimit을 넘으면 롤아웃이 중단(Degraded)되고, 트래픽은 안정 버전(stable)으로 되돌아갑니다. 새 버전 파드는 스케일 다운되고, 원인을 고쳐 다시 배포하면 됩니다. 사람이 자는 동안에도 자동으로 이뤄지는 게 핵심 이점입니다.
setWeight만으로 트래픽이 정확히 나뉘나요?
트래픽 관리자를 연결하지 않으면 파드 수 비율로 근사할 뿐 정밀하지 않습니다. 정확한 가중치가 필요하면 Istio, Linkerd, NGINX Ingress, Gateway API 같은 트래픽 라우팅 통합을 함께 설정해야 합니다.
댓글 0