IL-0437 Gunosy · 2023-06-20 (게시일)kubernetes
카나리 배포가 끝나지 않은 상태에서 구 버전 파드가 새 ConfigMap 으로는 시작하지 못해 연쇄적으로 죽었다
Gunosy 의 이 서비스는 쿠버네티스 위에서 돌았다. 설정은 ConfigMap 으로, YAML 은 Helm 으로 관리했고, Argo Rollouts 로 파드 하나에 먼저 내보낸 뒤 문제가 없으면 전체로 롤아웃하는 카나리 배포를 했다. 장애 당일 그보다 앞서 옛 DB 를 폐기하려고 ConfigMap 과 코드에서 그 설정을 지우는 릴리스를 했지만, 파드 하나만 나간 상태에서 롤아웃 작업을 잊었다. Helm 으로 릴리스하면 파드는 새 버전과 구 버전이 함께 있어도 ConfigMap 같은 리소스는 기본으로 최신 것만 남는다. 서버는 시작할 때 ConfigMap 을 읽으므로 평소에는 문제가 드러나지 않았다.
뉴스 속보로 트래픽이 늘자 파드가 자동으로 늘어났는데, 롤아웃이 끝나지 않았으므로 늘어난 것은 구 버전 파드였다. 구 버전 파드는 옛 DB 의 설정이 필요했지만 새 ConfigMap 만 있어 시작하지 못했다. 파드가 늘지 못해 기존 파드에 부하가 몰려 재시작이 일어났고, 재시작한 파드도 ConfigMap 을 다시 읽다가 시작하지 못해 파드가 연쇄적으로 죽었다.
Gunosy 는 근본 원인을 두 가지로 보았다. 하나는 손으로 하는 롤아웃을 잊은 것이고, 다른 하나는 ConfigMap 이 최신 것만 남아 파드가 시작하지 못한 것이다. Argo Rollouts 를 자동 롤아웃으로 바꾸고, Helm 의 "helm.sh/resource-policy": keep 주석으로 지난 버전의 ConfigMap 을 남기며, 남긴 버전을 정리하는 Helm 플러그인을 만들어 넣었다.
- 심각도
- –
- 영향 범위
- Pods of the service failed to start and died in a cascade during a traffic surge from a breaking news alert
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
뉴스 속보로 트래픽이 늘어 파드가 자동으로 늘어나던 중, 새로 뜨는 파드가 설정을 읽지 못해 시작하지 못했다. 컨테이너가 재시작을 거듭하며 파드가 차례로 죽어 장애가 났다.
새로 늘어난 파드는 구 버전이었다. 구 버전 코드는 폐기한 옛 DB 의 설정을 읽어야 했지만, ConfigMap 에는 그 설정을 지운 새 버전만 남아 있었다.
파드가 늘지 못하자 기존 파드에 부하가 몰려 재시작이 일어났다. 재시작한 파드도 ConfigMap 을 다시 읽으면서 시작하지 못했고, 파드가 줄줄이 죽어 갔다.
증상 컨테이너 재시작 반복
원인
- 촉발
- 옛 DB 를 폐기하려고 ConfigMap 과 코드에서 그 설정을 지운 릴리스가 Argo Rollouts 카나리로 파드 하나에만 나갔고, 전체 롤아웃을 잊은 상태였다. 그때 뉴스 속보로 트래픽이 늘어 구 버전 파드가 늘어났다.
감지
–
조치
–
후속 조치
- Argo Rollouts 의 canary 단계를 setWeight: 1 뒤 pause duration: 1h 를 거쳐 setWeight: 100 으로 자동 롤아웃하도록 설정을 바꿨다.
- Helm 리소스에 "helm.sh/resource-policy": keep 주석을 달아 지난 버전의 ConfigMap 을 남기는 설정을 도입한다.
- ConfigMap 이름에 넣은 리비전 번호로 최신부터 순서를 확인해 지난 버전을 정리하는 Helm 플러그인 helm-clear 를 만들었다. CD 에서 helm clear configmap 에 --history 5 를 주어 지난 다섯 버전만 남기게 했다.
교훈
옛 DB 를 없애는 일은 드무니 다음에 조심하자는 회고로는 장애가 곧 다시 난다. 사람의 주의력은 믿을 수 없으므로, 재발을 막으려면 사람의 주의에 기대지 않는 장치를 만들어야 한다. Argo Rollouts 도입 초기에는 사람의 손을 거치지 않고 자동으로 롤아웃되는 것을 걱정했다. 그러나 몇 년 운영해 보니 오히려 롤아웃을 잊는 일이 더 많았고, 큰 릴리스는 어차피 Datadog 같은 감시 화면을 지켜보므로 거의 잊지 않았다. 지난 ConfigMap 을 남기자 ConfigMap 이 바뀐 릴리스도 CI/CD 를 거치지 않고 빠르게 롤백할 수 있게 되었다.
출처
참고 문서
관련 사례
IL-0324External Storage 데이터베이스 클러스터에 과부하가 걸려 mw-api-int, mw-parsoid, mw-jobrunner 의 지연과 데이터베이스 오류가 늘었다Wikimedia Foundation · 2025같은 원인 · 공통 컨피그맵과 시크릿, Helm
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0437
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0437/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.