Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례51건

51건 중 21~25번째

  1. IL-0182 트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다
    이언철2024
    증상

    트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.

    지연 시간 증가간헐적 연결 실패오토스케일러 오동작
    촉발

    트래픽이 급변하면서 수가 적은 CoreDNS 파드에 처리할 수 있는 양보다 많은 부하가 몰렸다.

    원인
    용량 한계
    구성 요소
    CoreDNSKarpenter수평 파드 오토스케일러파드 스케줄링과 배치
    기여 요인
    자동화 증폭수동 조치 악화
    조치
    • 클러스터 크기에 맞춰 CoreDNS replica 를 늘리도록 CPA 를 설정하고, 인스턴스 타입에 맞게 nodesPerReplica, coresPerReplica, replica 최솟값과 최댓값을 조정했다.
    • CoreDNS 에 anti-affinity 대신 ScheduleAnyway 로 느슨하게 한 topologySpreadConstraints 를 걸어, Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다.
    • CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 걸었다.
    • NodeLocal DNSCache 를 적용해 노드마다 DNS 캐시를 두고 메인 CoreDNS 의 부하를 낮췄다.
    교훈

    CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다.

    사례 보기
  2. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다
    UK Ministry of Justice2024
    증상

    2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

    모니터링 중단프로브 실패
    촉발

    계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

    원인
    용량 한계
    구성 요소
    Prometheus
    기여 요인
    기본 설정 방치한계 미인지
    감지

    계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

    조치
    • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.
    후속 조치
    • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
    • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
    • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
    • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
    • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
    • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
    • Amazon Managed Prometheus 를 간단히 조사한다.
    사례 보기
  3. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.
    DFDS2024
    증상

    2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

    노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단
    촉발

    Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

    원인
    용량 한계
    구성 요소
    텔레메트리 에이전트컨테이너 메모리 한도애플리케이션 데이터베이스
    기여 요인
    과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대
    감지

    10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

    조치
    • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
    • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
    • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
    • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
    • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
    • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.
    후속 조치
    • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
    • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
    • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
    • grafana-agent 의 메모리 사용량을 조사한다.
    • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
    • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
    • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.
    교훈

    포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

    사례 보기
  4. 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일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

    사례 보기
  5. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.
    Scaleway2024
    증상

    2024-01-24 23:48 CET, FR-PAR 리전에서 Kapsule 과 Kosmos 고객 클러스터의 일부 노드가 NotReady 로 바뀌었다. 같은 시각 API Gateway 로 들어오는 요청이 크게 치솟았다.

    노드 NotReadyOOMKilled간헐적 타임아웃모니터링 중단
    촉발

    FR-PAR 에서 동시에 몰린 배포가 Scaleway Kubernetes API 의 메모리를 바닥냈다.

    원인
    용량 한계
    구성 요소
    컨테이너 메모리 한도kubelet
    기여 요인
    단일 장애점재시도 폭주
    감지

    23:48 에 API Gateway 부하가 늘어난 것이 감지됐고, 00:00:10 에 내부 에스컬레이션을 거쳐 당직 엔지니어가 맡았다.

    조치
    • 관리형 Kubernetes 서비스의 메모리 한도와 가비지 컬렉션 임계값을 곧바로 올렸다.
    • 늘어난 부하를 받도록 주요 서비스에 복제본을 추가로 배포했다.
    • 레지스트리 캐시를 비우고, 클러스터가 안정되는 동안 지켜봤다.
    • 장애 뒤에도 계속 모니터링하며 서비스 설정을 조정했다.
    후속 조치
    • 로컬 인증 캐시를 구현한다.
    • 노드 인증 방식을 더 개선한다.
    • 모니터링을 강화하고 레이트 리밋 전략을 조정했으며 장애 대응 절차를 개선했다.
    교훈

    탄탄한 모니터링과 빠른 대응 체계가 중요하다. Kubernetes API 가 노드 인증까지 맡고 있어서 API 의 메모리 부족이 곧장 노드 NotReady 로 번졌다. Scaleway 는 이를 막으려고 로컬 인증 캐시와 노드 인증 개선을 계획했다.

    사례 보기
내 클러스터에도 있는지 확인하기

이 51건에서 가장 많이 나오는 구성 요소: 컨테이너 메모리 한도, 노드 풀. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

kubegap 열기

원인별1

용량 한계51건

구성 요소
컨테이너 메모리 한도12건노드 풀11건쿠버네티스 API 서버9건CoreDNS8건애플리케이션 데이터베이스6건kubelet6건Prometheus6건텔레메트리 에이전트6건클라이언트 쪽 DNS 리졸버와 캐시4건etcd4건파드 스케줄링과 배치4건인메모리 캐시3건수평 파드 오토스케일러3건인그레스 컨트롤러3건VPC 서브넷 또는 파드 주소 범위3건클러스터 오토스케일러2건conntrack 테이블2건컨테이너 런타임2건컨테이너 CPU 한도2건Karpenter2건kube-dns2건kube-proxy2건리눅스 커널2건노드 루트 디스크2건영구 볼륨과 스테이트풀셋2건공유 네트워크 파일 시스템2건AWS VPC CNI2건어드미션 웹훅1건CI 시스템1건Cilium1건클라우드 컨트롤러 매니저1건파드용 자격 증명 중개자1건Elasticsearch 와 OpenSearch1건GKE 컨트롤 플레인1건HAProxy1건Helm1건Istio1건잡과 크론잡1건언어 런타임 설정1건NAT 게이트웨이1건클러스터 인증 제공자1건컨테이너 레지스트리와 자격 증명1건서비스 디스커버리1건학습 데이터 로더1건VPC DNS 리졸버1건
기여 요인
기본 설정 방치17건모니터링 사각지대13건한계 미인지12건단일 장애점12건재시도 폭주10건자동화 증폭7건과도한 영향 범위7건수동 조치 악화7건미검증 가정6건용량 계획 부재6건한계 경보 부재5건리소스 요청과 한도 미설정5건초기 신호 무시3건캐시 부재3건여유 용량 부재3건스테이징 불일치3건디버그 접근 제한2건단계적 배포 부재2건롤백 무효2건피크 시간 변경1건런북 부재1건장애 중첩1건
조직
UK Ministry of Justice5건2i2c3건Zalando3건Backpackr2건loveholidays2건Palark2건Scaleway2건Adevinta1건Airbnb1건BC Government1건Blue Matador1건Buildkite1건Civis Analytics1건Datadog1건DFDS1건DigitalOcean1건Fullstaq1건GitLab1건Google Cloud1건Honeycomb1건Hugging Face1건Kevin1건Lablup Inc1건LINE1건Linode1건Magic Pages1건Mercari1건Moonlight1건Neon1건Onkar Raghunath Shelke1건PostHog1건RebelMouse1건Render1건Saifeddine Rajhi1건Saltside1건Temporal1건Universe1건unknown1건이언철1건
  1. IL-0071 작은 파일이 4만 개 넘게 든 단일 스테이지 이미지의 containerd 스냅샷이 쌓여 워커 노드의 inode 가 디스크보다 빠르게 소진되고 있었다
    Onkar Raghunath Shelke2026
  2. IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.
    Buildkite2026
  3. IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다
    DigitalOcean2026
  4. IL-0137 60노드 B200 학습 클러스터에서 노드들의 작은 랜덤 I/O 가 VAST 스토리지의 메타데이터 서비스를 포화시켜 학습 초기화가 8시간 넘게 걸렸다
    Lablup Inc2026
  5. IL-0181 외부 커뮤니티 게시글로 트래픽이 몰려 상품 API 파드가 CPU limit 1코어에서 스로틀링되면서 상품 조회 페이지가 매우 느려졌다
    Kevin2026
  6. IL-0129 SmolLM3 사전 학습에서 공유 Weka 스토리지가 데이터셋 샤드를 S3 로 내보내고 Nanotron 데이터로더의 인덱스가 스텝마다 커지면서, 학습을 시작한 지 몇 시간 만에 처리량이 거듭 급락했다.
    Hugging Face2025
  7. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.
    PostHog2025
  8. IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.
    unknown2025
  9. IL-0067 Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다
    BC Government2025
  10. IL-0080 트래픽이 몰린 GKE 클러스터에서 kube-dns 가 DNS 질의를 감당하지 못해 여러 서비스의 이름 해석이 실패하고 운영 장애로 번졌다.
    Mercari2025
  11. IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.
    RebelMouse2025
  12. IL-0006 AWS VPC CNI 가 자원이 찬 노드에 IP 를 붙잡아 두어 us-east-1 서브넷 IP 가 바닥났고, WARM_IP_TARGET 을 바꾼 조치가 파드 시작 실패를 더 오래 끌었다
    Neon2025
  13. IL-0099 메모리 상한 없이 8GB 만 보장한 프로필 때문에 워크숍 중 사용자 파드가 서로를 축출해 서버 시작이 15분을 넘고 커널이 죽었다.
    2i2c2025
  14. IL-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.
    Backpackr2025
  15. IL-0027 CoreDNS 파드가 모두 한 노드에 몰린 채 그 노드의 메모리가 고갈되자 DNS 가 응답하지 못해 아이디어스 서비스 전체가 멈췄다
    Backpackr2025
  16. IL-0085 Hetzner Cloud 의 k3s 컨트롤 플레인 노드가 메모리 부족으로 꺼진 뒤 클러스터가 Hetzner API 호출 한도를 다 써 버려 모든 고객 사이트가 약 7.5시간 멈췄다.
    Magic Pages2025
  17. IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.
    Render2024
  18. IL-0007 EKS 클러스터에서 VPC-CNI 가 파드마다 VPC IP 를 쓰다가 서브넷 IP 가 바닥나 파드가 IP 를 받지 못했다
    Adevinta2024
  19. IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.
    UK Ministry of Justice2024
  20. IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다
    Saifeddine Rajhi2024
  21. IL-0182 트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다
    이언철2024
  22. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다
    UK Ministry of Justice2024
  23. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.
    DFDS2024
  24. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.
    Scaleway2024
  25. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.
    Scaleway2024
  26. IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다
    Honeycomb2023
  27. IL-0043 새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌어 Kibana의 애플리케이션 로그에 긴 공백이 생겼다
    UK Ministry of Justice2023
  28. IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다
    UK Ministry of Justice2023
  29. IL-0028 쿠버네티스에서 Temporal History 파드가 CPU 사용률이 60% 아래인데도 CPU 스로틀링을 받아 요청 지연이 불안정했다
    Temporal2023
  30. IL-0195 200개가 넘는 노드의 고객 클러스터에서 Cilium 파드가 LIST 요청을 한꺼번에 쏟아내 kube-apiserver 가 메모리를 다 쓰고 죽기를 되풀이했다.
    Palark2023
  31. IL-0165 프랑크푸르트 LKE 의 백엔드 서비스가 메모리 부족으로 실패해 일부 사용자가 kubectl 로 kube-apiserver 에 접속하지 못했다
    Linode2023
  32. IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.
    Palark2023
  33. IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다
    2i2c2023
  34. IL-0140 us-central1 의 GKE API 가 지연과 오류를 내면서 고객이 클러스터 상태 확인, 업그레이드, 생성과 삭제를 하지 못했다.
    Google Cloud2022
  35. IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.
    GitLab2022
  36. IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.
    2i2c2020
  37. IL-0093 리더 ingress 컨트롤러 파드가 공유 메모리를 다 써서 ingress 컨트롤러 파드 6개 중 4개가 크래시 루프에 빠졌다
    UK Ministry of Justice2020
  38. IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.
    LINE2020
  39. IL-0013 노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다
    loveholidays2020
  40. IL-0015 GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다
    loveholidays2020
  41. IL-0033 kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다
    Airbnb2019
  42. IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다
    Blue Matador2019
  43. IL-0002 빌더 파드가 노드 한 대에 몰리자 kubelet 이 기본 API QPS 한도에 막혀 파드 상태를 늦게 갱신했고, CI 빌드가 AWS IAM 자격 증명을 받지 못해 실패했다
    Zalando2019
  44. IL-0076 dex의 AuthRequest 리소스가 끝없이 쌓였고, 이를 치우려고 네임스페이스를 지우자 목록 조회 타임아웃과 재시도가 반복되며 쿠버네티스 마스터가 내려갔다
    Fullstaq2019
  45. IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다
    Datadog2019
  46. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.
    Moonlight2019
  47. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.
    Civis Analytics2019
  48. IL-0001 CoreDNS 파드가 메모리 한도 100Mi 에 걸려 OOM 으로 계속 죽으면서 쿠버네티스 클러스터 전체의 DNS 가 멈췄다
    Zalando2019
  49. IL-0031 API 서버가 OOMKill로 죽자 Skipper 인그레스가 라우트를 잃었고, 고객 트래픽이 끊기며 IAM 서비스에서 404 오류가 났다
    Zalando2018
  50. IL-0036 재시도를 멈추지 않는 쿠버네티스 Job 이 노드 자원을 다 써 버려 클러스터의 노드가 차례로 죽고 검색과 리포트가 멈췄다.
    Universe2017
  51. IL-0040 비운영 쿠버네티스 클러스터에 Helm 차트를 한꺼번에 설치하자 작은 gp2 루트 볼륨의 IOPS 가 바닥나, 워커 노드 세 대에서 kubelet 이나 Docker 가 내려가 세 대 모두 NotReady 가 됐다
    Saltside2017