사례10건

10건 중 1~5번째

1. IL-0464 IONOS 관리형 쿠버네티스의 고객 컨트롤 플레인 일부가 사흘 동안 몇 분씩 되풀이해 끊겼다

   IONOS Cloud2026

   증상

   2026-03-14 부터 고객의 관리형 쿠버네티스 컨트롤 플레인 일부가 주기적으로 응답하지 않았다. 영향받은 클러스터에는 그때마다 몇 분씩 닿을 수 없었고, 배포, 스케일링, 헬스체크처럼 쿠버네티스 API 에 기대는 작업이 제대로 동작하지 않았다. 상태 페이지에는 2026-03-16 08:24 UTC 에 일부 고객이 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪을 수 있다고 처음 올라왔다.

   컨트롤 플레인 무응답이미지 풀 실패

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위

   조치

   • 영향받은 데이터베이스 인스턴스를 조각 모음해 인스턴스마다 약 3–4 GiB 를 되찾고 정상 운영 여유를 되돌렸다.
   • 영향받은 인스턴스에서 데이터베이스 컴팩션 주기를 줄였다.
   • 03-16 11:37 UTC 에 쿠버네티스 팀이 영향받은 AI Model Hub 데이터베이스 서비스에 수정을 배포했다.
   • 03-16 19:58 UTC 에 영향받은 모든 클러스터에 마지막 변경을 적용했다.

   후속 조치

   • 데이터베이스 인스턴스별 컨트롤 플레인 상태가 잘 보이도록 모니터링 대시보드를 넓힌다.
   • 데이터가 가장 많은 클러스터를 전용 데이터베이스 백엔드로 옮겨 그 워크로드가 같은 데이터베이스 인스턴스의 다른 클러스터에 주는 영향을 없앤다.
   • 이런 장애가 나면 곧바로 호출 알림이 가서 사람이 제때 개입하도록 알림을 개선한다.
   • 바꾼 컴팩션 주기를 모든 공유 컨트롤 플레인 데이터베이스 인스턴스에 적용한다.
   • 조각화가 쌓이지 않도록 모든 인스턴스에 정해진 일정으로 도는 자동 조각 모음 작업을 둔다.
   • 한곳에 몰리는 위험을 줄이도록 데이터베이스 인스턴스 사이의 클러스터 배치를 다시 맞춘다.
   • 4주 안에 데이터를 지나치게 많이 만드는 클러스터의 고객에게 직접 연락해, 큰 보안 스캔 보고서를 컨트롤 플레인 데이터베이스가 아닌 외부 스토리지 백엔드에 두는 것 같은 워크로드 최적화를 논의한다.
   • 1~3개월 안에 공유 컨트롤 플레인 데이터베이스에 테넌트별 자원 쿼터와 키 개수 한도를 두어, 클러스터 하나가 다른 클러스터에 영향을 주지 못하게 한다.
   • 2026년 2분기부터 공유 컨트롤 플레인을 다시 설계해 전용 데이터베이스 인스턴스를 두고 수직 확장을 개선해 고객 워크로드 사이의 격리를 강화한다.
   • 데이터가 꾸준히 많은 고객을 위해 데이터베이스를 완전히 샤딩하는 방안을 검토한다.
   • 다음 장애의 대응 시간을 줄이도록 데이터베이스 자원 고갈과 복구를 다루는 운영 훈련을 정기적으로 한다.

   사례 보기
2. IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.

   Render2024

   증상

   2022년 1월 Render 의 프랑크푸르트 Kubernetes 클러스터 하나에서 새 배포와 크론 잡 실행이 실패했다. etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸린 상태였다.

   컨트롤 플레인 무응답배포 실패DNS 조회 실패오류율 상승

   촉발

   etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다.

   원인

   용량 한계

   구성 요소

   etcdCoreDNS쿠버네티스 API 서버

   기여 요인

   기본 설정 방치수동 조치 악화

   후속 조치

   • CoreDNS 를 컨트롤 플레인 노드가 아닌 데이터 플레인 노드에서 돌게 했다.
   • etcd 를 전용 노드에서 돌게 했다.

   교훈

   CoreDNS 는 API 서버가 내려가 있어도 메모리 캐시로 DNS 질의에 답할 수 있지만, 초기화할 때는 API 서버가 필요하다. CoreDNS 가 컨트롤 플레인 노드에 있었기 때문에, 컨트롤 플레인 장애 중에 노드를 재부팅하자 새 배포와 크론 잡만 실패하던 장애가 이미 돌던 서비스로 가는 요청까지 실패하는 장애로 커졌다. 핵심 문제는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되어 있지 않았다는 점이다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 CoreDNS 가 재시작될 수 있었다.

   사례 보기
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" 상태가 됐다.

   노드 NotReady컨트롤 플레인 지연OOMKilled

   촉발

   2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   재시도 폭주자동화 증폭단계적 배포 부재

   감지

   타임라인의 첫 기록은 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일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

   사례 보기
4. IL-0195 200개가 넘는 노드의 고객 클러스터에서 Cilium 파드가 LIST 요청을 한꺼번에 쏟아내 kube-apiserver 가 메모리를 다 쓰고 죽기를 되풀이했다.

   Palark2023

   증상

   어느 평범한 아침, 기술 지원 엔지니어가 전화로 고객 클러스터가 프로덕션 환경까지 포함해 사실상 동작하지 않는다고 알려 왔다. 클러스터에 접속해 보니 kube-apiserver 가 메모리를 전부 써 버린 상태였다.

   컨트롤 플레인 무응답OOMKilled

   촉발

   200개가 넘는 노드에서 Cilium 파드가 쿠버네티스 API 에 LIST 요청을 동시에 대량으로 보냈다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버Cilium

   기여 요인

   기본 설정 방치

   감지

   기술 지원 엔지니어가 전화로 고객 클러스터가 사실상 동작하지 않는다고 알렸다. 요청을 보낸 쪽을 찾을 때는 Grafana 대시보드에서 API 요청 수가 급증한 것을 먼저 보았고, Prometheus 의 apiserver_request_total 을 인스턴스와 리소스별로 묶어 Cilium 네트워크 정책 쪽 LIST 요청을 찾았다. 감사 로그로 실제 요청도 확인했다.

   조치

   • 컨트롤 플레인 노드에 CPU 와 메모리를 두 차례에 걸쳐 더해 CPU 8개, 메모리 16 GB 에서 CPU 16개, 메모리 64 GB 로 늘렸고, 두 번째 증설 뒤 API 가 안정됐다.
   • 고객과 합의한 시험 시간에 cilium-agent 를 재시작해 API 서버가 하나씩 메모리를 다 쓰고 죽는 흐름을 확인했다.
   • d8-cni-cilium 서비스 어카운트의 cilium.io list 요청을 묶는 cilium-pods FlowSchema 와, 이 요청의 동시 처리 수를 제한하는 cilium-pods PriorityLevelConfiguration 을 만들어 클러스터에 배포했다.
   • cilium-agent 를 재시작해도 메모리 사용량이 크게 변하지 않는 것을 확인한 뒤 컨트롤 플레인 노드 자원을 원래 크기로 줄였다.

   후속 조치

   • API 요청을 제한해야 했던 일을 여러 번 겪은 뒤, API Priority and Fairness 설정을 Palark 쿠버네티스 플랫폼의 기본 구성으로 넣었다.

   교훈

   특정 클라이언트의 요청을 API Priority and Fairness 의 별도 우선순위 수준에 묶어 두면, 그 클라이언트가 요청을 쏟아내도 사용자 요청이 밀리지 않고 API 서버도 버틴다. API 서버 전체의 동시 처리 한도는 --max-requests-inflight 기본값 400 과 --max-mutating-requests-inflight 기본값 200 을 더한 값이다. API 서버는 이 한도를 각 우선순위 수준의 assuredConcurrencyShares 비율대로 나누므로, 한 수준의 값을 올리면 다른 수준의 한도는 줄어든다. 로그 보기나 exec 같은 오래 걸리는 요청과 WATCH 요청은 이 한도에 걸리지 않는다. 큐 개수, queueLengthLimit, handSize 는 요청이 너무 느려지지 않으면서 갑작스러운 폭증에도 API 서버가 넘치지 않도록 실험으로 정해야 한다. 지켜볼 지표로는 apiserver_flowcontrol_rejected_requests_total, apiserver_current_inqueue_requests, apiserver_flowcontrol_request_execution_seconds 가 있다. Palark 는 이런 일을 이번 말고도 여러 번 겪었다.

   사례 보기
5. IL-0165 프랑크푸르트 LKE 의 백엔드 서비스가 메모리 부족으로 실패해 일부 사용자가 kubectl 로 kube-apiserver 에 접속하지 못했다

   Linode2023

   증상

   2023-05-25 14:11 UTC 에 Linode 는 프랑크푸르트 데이터센터의 일부 LKE 사용자가 kubectl 로 자기 kube-apiserver 에 닿지 못한다는 것을 알게 되었다.

   컨트롤 플레인 무응답

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버컨테이너 메모리 한도

   기여 요인

   –

   감지

   Linode 는 14:11 UTC 에 문제를 알게 되었다. 백엔드 서비스가 실패하기 시작한 지 11분 뒤였다.

   조치

   • 메모리 한도를 올렸다.

   후속 조치

   • 영향받은 LKE 구성 요소의 복원력, 이중화, 모니터링을 늘린다.

   사례 보기

원인별1