Istio private ingressgateway를 Helm으로 재배포하는 과정에서 43분간 장애가 발생했다. 이미지 서명 정책, Helm values 누락과 수동 변경 이력이 함께 영향을 준 사례다. 장애 경과와 원인, 이후 적용한 재발 방지 조치를 정리한다.
무슨 일이 있었나
- 소요 시간: 발견부터 복구까지 약 43분
- 증상: private ingressgateway로 유입되는 트래픽 처리 실패, 다수 서비스에서 5XX 발생
- 트리거: ingressgateway 대상 Helm upgrade
타임라인
| 경과 | 작업 | 결과 |
|---|---|---|
| T+0 | ingressgateway Helm upgrade 수행 | Kyverno 이미지 서명 정책 위반으로 patch 거부. 기존 Pod는 종료되고 신규 Pod는 생성되지 않아 서비스 중단 |
| 약 7분 | 이전 릴리스로 Helm rollback 시도 | values.yaml 필수 설정 누락으로 ingressgateway 미생성. 복구 실패 |
| 약 12분 | 기존 Helm values 점검 | LoadBalancer용 필수 annotation 누락 확인 |
| 약 39분 | 정상 동작하던 Deployment를 YAML로 추출 | 누락된 필드·annotation 확인 |
| 약 40분 | 누락 항목을 채워 kubectl apply로 수동 복원 | ingressgateway 정상 생성, 서비스 복구 |
| 약 43분 | 정상화 확인 | — |
근본 원인
여러 원인이 동시에 발생하면서 배포뿐 아니라 롤백 경로도 정상적으로 동작하지 않았다.
- 서명되지 않은 외부 이미지 — 배포에 쓰인 Istio 이미지가 public registry 출처였고 서명이 없었다. values에서 image 설정이 누락돼
image: auto로 처리되면서 서명 검증에 걸렸고, Kyverno 정책이 배포를 차단했다. - 기존 Pod 종료 후 신규 Pod 생성 실패 — patch가 거부되는 사이 기존 Pod는 종료됐고 신규 Pod는 정책에 의해 생성되지 못했다.
- 롤백도 실패 — 되돌리려 했지만 이전 릴리스의 values에도 필수 값이 빠져 있어 복원되지 않았다.
- 상태 불일치 — 과거에 수동으로 리소스를 수정한 이력이 있어 Helm이 알고 있는 상태와 실제 클러스터 리소스가 어긋나 있었다.
정리하면 이미지 정책으로 신규 배포가 실패했고, 이전 릴리스의 values 누락 때문에 롤백도 실패했다. 최종적으로 정상 동작하던 리소스와 비교해 누락 항목을 복원해야 했다.
배운 것
- 외부 이미지는 서명 정책 적용 여부를 미리 확인하자. Kyverno 같은 정책이 걸려 있으면
image: auto나 public 이미지는 그대로 막힌다. - 기본값(auto)에 기대지 말자. values 한 줄이 빠진 탓에 배포와 복구가 동시에 막혔다.
- 수동 리소스 수정은 최소화하되 했다면 반드시 기록하자. Helm 상태와 실제가 어긋나는 순간 롤백을 믿을 수 없게 된다.
- Helm과 YAML을 함께 운영하지 말자. 배포 방식은 하나로 일원화해야 한다.
재발 방지
- 핵심 구성요소는 Private Registry의 서명된 이미지로만 배포
- Helm chart 단일 소스 배포 — 수동 개입 지양, 변경 이력 통합 관리
- 클러스터에 ArgoCD를 연동해 배포·롤백을 GitOps로 자동화 (수동 적용 대신 Git 상태와 동기화)
- 배포 전 Helm values 크로스 체크 + QA 선검증 필수
- 상용 작업은 rollback 전략을 포함한 변경 계획 수립 후 진행
ArgoCD 연동은 이 장애 이후 진행했다. 수동 배포와 Helm·YAML 병행 관리가 복구를 지연시킨 원인이었기 때문에, 배포 정의와 변경 이력을 GitOps로 일원화했다.
마치며
Kyverno는 서명되지 않은 이미지를 차단하도록 설정된 정책대로 동작했다. 문제는 해당 정책을 전제로 배포 파이프라인과 values 관리 절차를 함께 변경하지 않은 데 있었다. 보안 정책을 도입할 때는 차단 조건뿐 아니라 정책이 작동했을 때의 복구 경로와 설정 관리 절차까지 함께 설계해야 한다.
참고