DevOps
[DevOps] Argo Rollouts
Jflip
2024. 12. 23. 09:53
728x90
1. 개요
Argo Rollouts는 Kubernetes 환경에서 고급 배포 전략을 구현할 수 있는 컨트롤러입니다.
기존 Kubernetes Deployment 컨트롤러는 기본적인 RollingUpdate 전략만 제공하지만,
Argo Rollouts를 통해서는 블루-그린 배포, 카나리 배포, 프로그레시브 딜리버리와 같은 현대적인 배포 전략을 Kubernetes 환경에 적용할 수 있습니다. 또한, 자동 롤백, 트래픽 제어, 비즈니스 메트릭 기반 배포 분석 등을 지원하여 안정적인 배포 프로세스를 구현할 수 있습니다.
2. 기존 쿠버네티스 배포의 한계점
기존 Kubernetes의 Deployment는 RollingUpdate 전략을 사용하여 배포를 처리하지만, 다음과 같은 한계가 존재합니다:
- 트래픽 제어의 한계: 새로운 버전으로 트래픽을 점진적으로 전환하는 기능이 부족합니다.
- 새 버전으로의 점진적 트래픽 전환 불가: 모든 트래픽을 한 번에 새로운 버전으로 전환해야 하므로, 트래픽 제어가 어려운 상황이 발생할 수 있습니다.
- 특정 사용자 그룹에 대한 타겟팅 불가: 특정 사용자에게만 새로운 버전을 배포하는 기능이 부족합니다.
- 배포 안정성 검증의 어려움: 기본적인
readiness probe만으로는 배포의 안정성을 충분히 검증하기 어렵습니다. - 비즈니스 메트릭 기반 검증 불가: 트래픽 전환의 성공 여부를 비즈니스 메트릭에 기반하여 검증할 수 없습니다.
- 자동 롤백 메커니즘 부재: 배포 실패 시, 수동으로 롤백을 해야 하며, 자동화된 롤백 메커니즘이 없습니다.
- 고급 배포 전략 미지원:
RollingUpdate외의 배포 전략(블루-그린, 카나리 배포 등)을 지원하지 않습니다. - A/B 테스팅 불가: 여러 버전 간의 비교 테스트를 위한 A/B 테스팅을 지원하지 않습니다.
Argo Rollouts는 이러한 한계를 극복할 수 있는 여러 기능을 제공합니다.
3. Argo Rollouts 주요 기능
1. 블루-그린 배포 전략
블루-그린 배포는 새로운 버전을 완전히 배포한 후, 트래픽을 전환하는 방식으로 배포합니다. 기존 버전과 새 버전이 동시에 실행되며, 트래픽은 새 버전으로 안전하게 전환됩니다.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-bluegreen
spec:
replicas: 3
strategy:
blueGreen:
activeService: rollout-bluegreen-active
previewService: rollout-bluegreen-preview
autoPromotionEnabled: false
prePromotionAnalysis:
templates:
- templateName: success-rate
scaleDownDelaySeconds: 600 # 이전 버전 유지 시간
template:
metadata:
labels:
app: rollout-bluegreen
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:blue
resources:
requests:
memory: 32Mi
cpu: 5m- activeService와 previewService를 사용해, 두 서비스 간의 트래픽을 관리합니다.
- autoPromotionEnabled를 false로 설정하면 수동으로 트래픽을 전환할 수 있습니다.
2. 카나리 배포 전략
카나리 배포는 새 버전을 점진적으로 배포하면서 트래픽을 점차적으로 전환하는 방식입니다. 카나리 배포는 실패 조건을 설정하고, 트래픽 비율을 단계적으로 증가시켜 안정성을 검증합니다.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
replicas: 5
strategy:
canary:
analysis:
templates:
- templateName: success-rate
startingStep: 2
steps:
- setWeight: 20
- pause: {duration: 10m}
- setWeight: 40
- pause: {duration: 10m}
- setWeight: 60
- pause: {duration: 10m}
- setWeight: 80
- pause: {duration: 10m}
trafficRouting:
nginx:
stableIngress: rollout-stable
additionalIngressAnnotations:
nginx.ingress.kubernetes.io/custom-header: "true"
template:
metadata:
labels:
app: rollout-canary
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:red
resources:
requests:
memory: 32Mi
cpu: 5msetWeight와pause를 사용하여 트래픽 전환을 점진적으로 진행할 수 있습니다. (이때, pause: {}로 설정하면 비활성화로 설정할 수 있습니다.)- trafficRouting 설정을 통해
NGINX와 같은 ingress 컨트롤러와 통합하여 트래픽을 제어합니다.
3. 메트릭 기반 분석
배포의 성공 여부를 메트릭 기반으로 판단할 수 있습니다.
Argo Rollouts는 Prometheus와 같은 메트릭 제공자를 통해 실시간으로 성능을 모니터링하고, 성공/실패 조건을 정의할 수 있습니다.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
metrics:
- name: success-rate
interval: 5m
count: 2
successCondition: result[0] >= 0.95
failureCondition: result[0] < 0.85
failureLimit: 2
provider:
prometheus:
address: http://prometheus.monitoring.svc.cluster.local:9090
query: |
sum(rate(http_request_total{job="{{args.service-name}}",status!~"5.*"}[5m])) /
sum(rate(http_request_total{job="{{args.service-name}}"}[5m]))
- name: latency-p95
interval: 5m
count: 2
successCondition: result[0] <= 0.5
failureCondition: result[0] > 1
provider:
prometheus:
address: http://prometheus.monitoring.svc.cluster.local:9090
query: |
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket{job="{{args.service-name}}"}[5m])) by (le))- successCondition와 failureCondition을 설정하여 메트릭을 기준으로 배포를 검증합니다.
- Prometheus 쿼리 결과에 따라 자동으로 승격 또는 롤백이 수행됩니다.
4. 구축 시 고려사항
1. 리소스 설정
- CPU: 최소 200m
- Memory: 최소 256Mi
- 추가적으로 분석 작업을 위한 리소스도 고려해야 합니다.
2. 네트워킹 구성
- 서비스 메시 (선택 사항): Istio, Linkerd
- 인그레스 컨트롤러: NGINX, ALB
- 서비스 디스커버리: Kubernetes에서 제공하는 서비스 디스커버리 기능
3. 모니터링 및 알림
- Prometheus + Grafana 설정
- Alerting rules 구성
- 배포 실패 시 알림 설정
5. 실제 운영 시 모범 사례
- 점진적 도입: 카나리 배포부터 시작하여 블루-그린 배포로 확장합니다.
- 메트릭 임계값 보수적 설정: 임계값을 너무 공격적으로 설정하지 말고, 실패를 최소화합니다.
- 배포 전략 선택: 서비스 특성에 따라 적합한 배포 전략을 선택합니다.
1. 애플리케이션 호환성 검토
적합한 애플리케이션
- 지속적인 배포가 필요한 애플리케이션
- 동시에 여러 버전 실행이 가능한 애플리케이션
- 소스 코드 접근 및 수정이 가능한 애플리케이션
부적합한 애플리케이션
- 공유 리소스를 사용하는 애플리케이션 (예: 공유 파일 시스템)
- 큐 기반의 워커 애플리케이션 (코드 수정 없이는 부적합)
- 인프라 구성요소 (cert-manager, nginx, coredns 등)
사용 범위와 제한사항
- 단일 클러스터 범위
- 단일 Kubernetes 배포/애플리케이션만 관리
- 다중 클러스터의 경우 각 클러스터에 컨트롤러 필요
- 배포 시간 고려사항
- 권장 배포 시간: 15-20분 ~ 1-2시간
- 장기 실행 배포(수일~수주)는 부적합
- 동시 다중 버전 운영은 미지원
실전 운영 팁
1. 메트릭 기반 자동화
- 완전 자동화된 배포를 목표로 설정
- 5-15분 내 배포 성공 여부 판단 가능한 메트릭 구성
- 수동 프로모션은 테스트 용도로만 사용
2. 시스템 통합 방안
# Kubernetes Downward API 활용 예시
spec:
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
env:
- name: POD_LABELS
valueFrom:
fieldRef:
fieldPath: metadata.labels3. 트래픽 라우팅 전략
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: service-rollout
spec:
rules:
- host: preview.example.com # 프리뷰 환경
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-preview
port:
number: 80
- host: stable.example.com # 안정 환경
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-stable
port:
number: 804. 리소스 최적화
- RevisionHistoryLimit 조정으로 메모리 사용량 최적화
- 대규모 클러스터에서는 10에서 5 또는 그 이하로 조정 권장
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: example-rollout
spec:
revisionHistoryLimit: 5 # 기본값 10에서 조정도입을 위한 체크리스트
- 애플리케이션 평가
- 동시 실행 가능성 검토
- 공유 리소스 의존성 확인
- 코드 수정 필요성 평가
- 메트릭 준비
- 핵심 성능 지표 정의
- 자동화된 판단 기준 수립
- 모니터링 시스템 연동
- 운영 계획 수립
- 점진적 도입 전략
- 롤백 절차 마련
- 운영팀 교육 계획
이러한 고려사항들을 바탕으로 Argo Rollouts를 도입한다면, 안정적이고 효과적인 배포 자동화를 실현할 수 있습니다.
https://argo-rollouts.readthedocs.io/en/stable/best-practices/
728x90
반응형