사례3건
3건 중 1~3번째
IL-0168새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.Scaleway2024- 증상
2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.
- 촉발
2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.
- 조치
- Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다.
- 02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다.
- 03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 "Ready" 가 되게 했다.
- 03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다.
- 15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다.
- 노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다.
- 후속 조치
- Kubernetes API 자원 배정을 늘렸다.
- 예전 인증 방식으로 롤백했다.
- 노드에 로컬 인증 캐시를 둔다.
- 부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다.
- 쿠버네티스에 새 요청 큐잉 방식을 넣는다.
- 높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다.
- 몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다.
- 이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다.
- 교훈
고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.
IL-0152정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정이 들어가 그 위에서 돌던 DOKS 클러스터 200개의 컨트롤 플레인이 자동으로 삭제됐다.DigitalOcean2024- 증상
2024-01-23 13:02 UTC 에 DigitalOcean 은 12:18 UTC 부터 FRA1 리전의 쿠버네티스 클러스터 문제를 조사하고 있다고 공지했다. 사용자는 FRA1 클러스터와 통신할 때 오류를 겪을 수 있었다.
- 촉발
정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정 변경이 실수로 적용됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
13:02 UTC 의 첫 상태 페이지 공지는 12:18 UTC 부터 조사 중이라고 했다. 사후 보고서의 타임라인에서는 12:36 에 잘못된 설정을 원인으로 확인했다.
- 조치
- 영향받은 클러스터마다 가장 최근 백업으로 etcd 클러스터를 되살렸다.
- etcd 를 되살린 뒤 상태가 없는 컨트롤 플레인 컴포넌트를 다시 올려 컨트롤 플레인 복구를 마쳤다.
- 13:00 에 복구 중 예상하지 못한 문제가 생기자 복구 메커니즘을 추가로 패치했고, 15:00 에 문제를 모두 해결했다.
- 복구 도중 추가로 발견한 작은 버그를 고쳤다.
- 고객지원팀이 영향받은 고객에게 직접 연락해 다음 조치를 안내했다.
- 후속 조치
- 운영 환경에서 어떤 경우에도 인프라 클러스터 자원이 자동으로 삭제되지 않게 막는 수정을 배포했다.
- 교훈
컨트롤 플레인을 받치는 인프라 클러스터의 설정 변경 하나가 한 리전의 DOKS 클러스터 200개의 컨트롤 플레인을 한꺼번에 지웠다. 하루 두 번 받아 둔 etcd 백업으로 클러스터를 되살릴 수 있었지만, 컨트롤 플레인 데이터는 백업 주기만큼, 최대 12시간 전 상태로 돌아갔다. 컨트롤 플레인이 사라진 동안에도 노드의 워크로드는 계속 돌았다.
- 증상
Jetstack 은 europe-west1 에 있는 GKE 리전 클러스터의 마스터를 업그레이드하고 있었다. 이 개발 클러스터는 여러 팀이 낮 동안 앱을 시험하는 데 쓴다. GKE Terraform 파이프라인으로 업그레이드를 시작했는데, 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않았다. GKE 콘솔에는 클러스터가 여전히 업그레이드 중으로 나왔다.
- 촉발
마스터 업그레이드 중 두 번째 마스터 인스턴스의 API 서버가 ca-registration PostStartHook 을 실행하면서 kube-system 의 extension-apiserver-authentication ConfigMap 을 갱신하려 했다. 이 요청은 설정해 둔 OPA 검증 웹훅의 백엔드가 응답하지 않아 타임아웃 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
GKE Terraform 파이프라인으로 시작한 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않은 것이 첫 신호였다. 파이프라인을 다시 돌리자 kube-apiserver 가 unhealthy 라는 오류가 났다. 원인은 Google Support 의 도움을 받아 찾았다.
- 조치
- API 서버에 간헐적으로 접근될 때를 이용해 OPA 의 ValidatingAdmissionWebhook 리소스를 지워 클러스터를 복구했다.
- 후속 조치
- OPA 의 ValidatingAdmissionWebhook 이 정책이 적용되고 개발 팀이 접근하는 네임스페이스만 보도록 범위를 좁혔다.
- 웹훅을 정책이 실제로 검증하는 Ingress 와 Service 리소스에만 켰다.
- OPA 가 응답하지 않으면 재시작되도록 liveness probe 를 더하고 문서를 고쳤다.
- 이 동작을 개선하자는 쿠버네티스 업스트림 이슈가 아직 열려 있어, 그 진행을 지켜본다.
- 교훈
API 서버 응답 시간에 알림을 걸어 두었다면, OPA 웹훅을 처음 배포한 뒤 모든 CREATE 와 UPDATE 요청의 응답 시간이 늘어난 것을 알아챘을 수도 있다. 모든 워크로드에 프로브를 설정하는 것이 중요하다. 팀은 OPA 배포가 너무 간단해 보여서 Helm 차트를 쓰지 않았는데, 그 차트에는 어드미션 컨트롤러 컨테이너의 livenessProbe 를 포함해 튜토리얼 기본 설정에 없는 조정이 여럿 들어 있었다. 노드 자동 복구를 끄는 것도 검토했지만 끄지 않기로 했다. 같은 문제를 겪은 것은 Jetstack 이 처음이 아니며, 관련 업스트림 이슈는 아직 열려 있다.
이 3건에서 가장 많이 나오는 구성 요소: 쿠버네티스 API 서버, 어드미션 웹훅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.