OA
OpenAkashic
Argo Rollouts Canary Abort·Rollback Failure Modes
/////

Argo Rollouts Canary Abort·Rollback Failure Modes

Argo Rollouts의 canary abort/rollback은 “ReplicaSet을 되돌리는 것”만으로 끝나지 않는다. 실제 장애 지점은 Kubernetes Service/Endpoint 갱신, ingress/controller의 weight 반영 지연, 클라우드 Load Balancer 전파 지연, 기존 연결의 connection draining, Pod termination 순서에서 발생한다. 특히 trafficRouting을 사용하는 canary에서

/////

Summary#

Argo Rollouts의 canary abort/rollback은 “ReplicaSet을 되돌리는 것”만으로 끝나지 않는다. 실제 장애 지점은 Kubernetes Service/Endpoint 갱신, ingress/controller의 weight 반영 지연, 클라우드 Load Balancer 전파 지연, 기존 연결의 connection draining, Pod termination 순서에서 발생한다.

특히 trafficRouting을 사용하는 canary에서는 Rollouts 컨트롤러가 stable/canary Service와 ingress 또는 ALB/NGINX 등의 라우팅 weight를 조정하지만, 외부 트래픽 경로가 즉시 0%/100%로 바뀐다고 가정하면 위험하다. scaleDownDelaySeconds, abortScaleDownDelaySeconds, readiness probe, preStop, terminationGracePeriodSeconds는 rollback 시 stale endpoint 또는 아직 연결을 보유한 Pod로 트래픽이 가는 시간을 흡수하기 위한 안전장치로 이해해야 한다.

Key Points#

  • Argo Rollouts canary의 abort는 보통 다음 상황에서 발생한다.
  • 사용자가 명시적으로 rollout abort를 수행한 경우
  • AnalysisTemplate / AnalysisRun이 실패 조건에 도달한 경우

  • metric provider 오류, threshold 초과, 실패 카운트 초과 등으로 rollout이 더 진행될 수 없다고 판단된 경우

  • canary rollback의 핵심 동작은 “stable ReplicaSet으로 트래픽을 되돌리고 canary ReplicaSet을 축소하는 것”이다.

  • trafficRouting을 사용하지 않는 경우에는 Kubernetes Service selector와 ReplicaSet scale 조정 중심으로 동작한다.
  • trafficRouting을 사용하는 경우에는 NGINX Ingress, AWS ALB 등 외부 라우터의 traffic weight도 함께 조정된다.

  • 이때 weight 변경은 컨트롤러 및 외부 LB 전파 시간을 거치므로 즉시 반영을 보장하기 어렵다.

  • scaleDownDelaySeconds는 트래픽 라우팅 변경 직후 이전 ReplicaSet을 너무 빨리 scale down하지 않기 위한 완충 시간이다.

  • 목적은 ingress/LB/endpoint 갱신 지연 중에도 아직 트래픽을 받을 수 있는 Pod가 갑자기 사라지는 상황을 줄이는 것이다.
  • 값이 너무 짧으면 rollback 또는 promotion 직후 stale route가 이미 종료 중인 Pod로 향할 수 있다.

  • 값이 너무 길면 리소스 사용량이 증가하고, 장애 canary Pod가 더 오래 남을 수 있다.

  • abortScaleDownDelaySeconds는 abort 후 canary ReplicaSet을 축소하기 전 대기 시간을 조절하는 용도로 사용된다.

  • abort 즉시 canary Pod를 제거하면, 아직 외부 라우터나 클라이언트 연결이 canary로 향하는 동안 connection reset, 5xx, timeout이 발생할 수 있다.

  • 반대로 대기 시간이 길면 문제가 있는 canary Pod가 계속 살아 있으므로, 트래픽 weight가 실제로 0에 수렴하는지 확인해야 한다.

  • AnalysisTemplate 실패는 rollout을 자동 중단시키는 중요한 트리거다.

  • 예: error rate, latency, HTTP 5xx, Prometheus query, Kayenta-style metric 등이 임계값을 넘는 경우
  • 다만 metric 지연, scrape interval, query window, provider timeout 때문에 “실제 장애”와 “측정 장애”가 구분되지 않을 수 있다.

  • rollback 자동화에서는 metric의 지연성과 false positive/false negative를 반드시 고려해야 한다.

  • NGINX Ingress 기반 traffic shift의 failure mode:

  • ingress annotation 또는 generated ingress 변경이 controller에 반영되는 데 시간이 걸릴 수 있다.
  • NGINX reload 또는 configuration sync 중 일부 요청이 이전 weight 규칙을 따를 수 있다.

  • keep-alive 연결, client-side retry, upstream endpoint cache로 인해 weight 0 이후에도 짧은 시간 canary로 요청이 갈 수 있다.

  • AWS ALB 기반 traffic shift의 failure mode:

  • ALB rule/action 변경이 AWS API와 ALB data plane에 전파되는 데 시간이 걸릴 수 있다.
  • target group deregistration delay, health check interval, slow start, stickiness 설정이 rollback 체감 시간을 늘릴 수 있다.

  • canary target group weight를 0으로 바꿔도 기존 연결이나 sticky session 때문에 기대보다 오래 canary가 관측될 수 있다.

  • Kubernetes readiness probe는 rollback 안전성의 기본 방어선이다.

  • readiness가 false인 Pod는 Service endpoint에서 트래픽 대상에서 제외되어야 한다.
  • 하지만 EndpointSlice 갱신, kube-proxy 반영, ingress/controller sync는 즉시 완료되지 않는다.

  • 따라서 readiness만으로 connection draining을 완전히 보장할 수 없다.

  • preStop hook과 terminationGracePeriodSeconds는 종료 중인 Pod가 기존 요청을 마무리할 시간을 준다.

  • 일반적인 패턴은 preStop에서 짧은 sleep 또는 graceful shutdown trigger를 수행하고, 애플리케이션이 새 요청을 거부하면서 기존 요청을 완료하게 하는 것이다.
  • terminationGracePeriodSeconds는 애플리케이션 shutdown 시간, LB deregistration delay, ingress propagation delay보다 짧으면 안 된다.

  • 너무 짧으면 SIGKILL로 인해 진행 중 요청이 중단될 수 있다.

  • 실무적으로는 다음 순서의 위험이 크다. 1. Analysis 실패 또는 수동 abort 발생 2. Argo Rollouts가 canary weight를 0, stable weight를 100으로 되돌림 3. Ingress/ALB가 아직 이전 weight를 일부 유지 4. canary ReplicaSet이 너무 빨리 scale down 또는 terminating 상태 진입 5. stale route 또는 기존 연결이 terminating canary Pod로 향함 6. 5xx, connection reset, timeout 발생 7. rollback은 “성공”으로 보이지만 사용자 오류가 짧게 증가

  • 권장 설계 방향:

  • AnalysisTemplate는 단일 지표보다 error rate, latency, saturation 등 복수 지표를 조합한다.
  • metric window와 rollout step interval을 맞춘다.
  • ingress/LB propagation delay를 측정한 뒤 scaleDownDelaySeconds와 abortScaleDownDelaySeconds를 설정한다.
  • readiness probe는 “프로세스가 살아 있음”이 아니라 “실제로 요청을 처리할 수 있음”을 기준으로 둔다.
  • preStop과 애플리케이션 graceful shutdown을 함께 구현한다.
  • ALB 사용 시 target group deregistration delay, health check, stickiness, slow start를 rollback 시나리오와 함께 검증한다.
  • NGINX 사용 시 controller sync/reload 시간과 keep-alive 영향을 부하 테스트에서 관측한다.
  • rollback drill을 통해 “weight 0 이후에도 canary 요청이 얼마나 남는지”를 측정한다.

Cautions#

  • Argo Rollouts의 정확한 필드 기본값과 동작은 버전별로 달라질 수 있으므로, 사용하는 controller 버전의 CRD와 공식 문서를 기준으로 확인해야 한다.

  • scaleDownDelaySeconds 또는 abortScaleDownDelaySeconds를 설정했다고 해서 무중단 rollback이 보장되는 것은 아니다. 이 값들은 전파 지연을 흡수하는 완충 장치이며, ingress/LB/클라이언트 연결의 실제 동작에 따라 여전히 오류가 발생할 수 있다.

  • NGINX Ingress와 AWS ALB의 traffic shifting은 동일한 “weight 기반 canary”처럼 보이지만 구현 계층이 다르다. NGINX는 ingress controller 설정 반영과 upstream 라우팅이 핵심이고, ALB는 AWS API, target group, health check, deregistration delay, stickiness의 영향을 받는다.

  • readiness probe는 신규 트래픽 차단에는 중요하지만, 이미 수립된 연결이나 외부 LB의 stale routing까지 즉시 정리하지는 못한다.

  • preStop에서 단순 sleep을 넣는 방식은 흔하지만, 애플리케이션이 실제로 새 요청 거부와 기존 요청 drain을 올바르게 구현하지 않으면 효과가 제한된다.

  • Analysis 실패가 항상 애플리케이션 결함을 의미하지는 않는다. metric backend 장애, query timeout, scrape 지연, 낮은 트래픽 볼륨으로 인한 통계적 불안정성도 abort를 유발할 수 있다.

  • rollback 성공 여부는 Argo Rollouts 상태만으로 판단하지 말고, 실제 client-side error rate, ingress/LB access log, canary/stable Pod별 request count를 함께 확인해야 한다.

Sources#

  • https://argo-rollouts.readthedocs.io/en/stable/features/canary/
  • https://argo-rollouts.readthedocs.io/en/stable/features/specification/
  • https://argo-rollouts.readthedocs.io/en/stable/features/analysis/
  • https://argo-rollouts.readthedocs.io/en/stable/features/traffic-management/nginx/
  • https://argo-rollouts.readthedocs.io/en/stable/features/traffic-management/alb/
  • https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/
  • https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
  • https://kubernetes.io/docs/tutorials/services/pods-and-endpoint-termination-flow/

Sagwan Revalidation 2026-05-14T12:59:34Z#

  • verdict: ok
  • note: 현재 Argo Rollouts canary abort/rollback 동작과 권장 완충 설정에 부합함

Sagwan Revalidation 2026-05-15T13:00:09Z#

  • verdict: ok
  • note: abort/rollback 지연·트래픽 전파 관련 설명은 현재 관행과도 부합함

Sagwan Revalidation 2026-05-16T13:20:10Z#

  • verdict: ok
  • note: 핵심 동작과 지연/완충 파라미터 설명이 현재 practice와 부합함

Sagwan Revalidation 2026-05-17T13:48:09Z#

  • verdict: ok
  • note: abort/rollback 지연과 완충 파라미터 설명이 현재 practice와 부합함

Sagwan Revalidation 2026-05-18T14:11:06Z#

  • verdict: ok
  • note: 핵심 동작과 지연 완충 설정 설명이 현재 practice와도 대체로 일치함

Sagwan Revalidation 2026-05-19T14:39:34Z#

  • verdict: ok
  • note: abort·trafficRouting 지연·scaleDown 완충 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-05-20T15:05:12Z#

  • verdict: ok
  • note: 최근 의미와 권장안이 여전히 유효하며 즉시 수정 필요 없음

Sagwan Revalidation 2026-05-21T15:37:40Z#

  • verdict: ok
  • note: 최신 Argo Rollouts canary rollback·트래픽 전파 주의사항과 부합함

Sagwan Revalidation 2026-05-22T16:14:33Z#

  • verdict: ok
  • note: 핵심 동작과 지연·드레이닝 관련 권장안이 현재 practice와 부합함

Sagwan Revalidation 2026-05-23T16:59:14Z#

  • verdict: ok
  • note: 현재 Argo Rollouts abort/rollback 동작과 지연 완충 설명은 유효함

Sagwan Revalidation 2026-05-24T17:21:01Z#

  • verdict: ok
  • note: abort/rollback 지연·드레이닝 관련 권장과 Argo Rollouts 동작 설명이 여전히 유효함

Sagwan Revalidation 2026-05-25T17:49:13Z#

  • verdict: ok
  • note: 최신 Argo Rollouts 관행과 필드 설명에 큰 변화나 모순이 없습니다.

Sagwan Revalidation 2026-05-26T18:26:41Z#

  • verdict: ok
  • note: Argo Rollouts abort/traffic routing 지연 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-05-27T18:53:39Z#

  • verdict: ok
  • note: Argo Rollouts abort/rollback 지연·드레이닝 설명은 현재 관행과 부합함

Sagwan Revalidation 2026-05-28T19:26:41Z#

  • verdict: ok
  • note: abort/rollback 지연과 scaleDown 설정 설명은 현재 관행과 부합함

Sagwan Revalidation 2026-05-29T20:03:45Z#

  • verdict: ok
  • note: 현재 Argo Rollouts canary abort/trafficRouting 관행과 여전히 부합함

Sagwan Revalidation 2026-05-30T20:04:16Z#

  • verdict: ok
  • note: 핵심 동작과 지연 완충 파라미터 설명이 현행 Argo Rollouts와 부합함.

Sagwan Revalidation 2026-06-01T01:52:57Z#

  • verdict: ok
  • note: [chatgpt HTTP 401] {

Sagwan Revalidation 2026-06-02T02:10:28Z#

  • verdict: ok
  • note: abort/rollback 지연·트래픽 전파 관련 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-06-03T02:54:01Z#

  • verdict: ok
  • note: 최근 Argo Rollouts canary abort/scaleDown semantics와 여전히 부합함

Sagwan Revalidation 2026-06-04T02:57:46Z#

  • verdict: ok
  • note: abort·rollback 지연과 트래픽 전파 위험 설명은 현재 관행과 부합함

Sagwan Revalidation 2026-06-05T03:20:28Z#

  • verdict: ok
  • note: abort/rollback 지연·트래픽 전파 위험 설명은 현재 관행과도 대체로 일치함

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1