IL-0110 DFDS · 2024-03-13kubernetesaws
DFDS 의 쿠버네티스 클러스터에서 2024-03-13 오전에 노드 하나가 NotReady 가 되어 새 노드로 교체됐다. 오후에는 그 새 노드에서 같은 일이 다시 일어났다.
근본 원인은 한 노드에서 Grafana Agent 파드가 메모리를 많이 쓰고 있던 것이었다. 같은 노드에 Hangfire 파드가 배치되자 시스템 OOM 으로 CrashLoopBackOff 가 꼬리를 물었고, 결국 노드 전체가 응답을 멈췄다. 문제의 Hangfire 파드는 개발용 컨테이너였다. 개발 워크로드가 운영 워크로드와 섞여 있었고, 모니터링 스택 대부분과 달리 grafana-agent 는 전용 노드 그룹에서 돌지 않았다.
첫 대응에서 팀은 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄우고, 문제 노드를 cordon 하고 강제로 drain 한 뒤 종료했다. cordon 은 노드에 새 파드가 배치되지 않게 막는 것이고, drain 은 노드의 파드를 내보내는 것이다. 이후 조사에서 새로 적용한 LimitRange 때문에 Grafana Agent 가 13:02 까지 내려가 있었던 것을 찾아 고쳤다. 개발 컨테이너를 0개로 줄이자 트래픽이 정상으로 돌아왔지만, 3개로 되돌리자 15:03 에 새 노드가 다시 NotReady 가 됐다. 팀은 15:15 에 개발 컨테이너를 다시 0개로 줄이고 담당 팀에 메일을 보냈고, 15:52 에 개발팀이 문제를 확인하고 수정에 들어갔다. 탐지까지 4분, 복구까지 399분이 걸렸다.
2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.
10:13 에 노드에 SSH 로 들어가려 했지만 노드가 응답하지 않았고, 10:19 에야 다시 응답했다. 10:25 에 CloudWatch 에서 장애 직전까지 EC2 네트워크 트래픽이 열 배로 늘어난 것을 보았다. 10:30 에는 문제 노드에서 Grafana Agent 가 돌고 있었고 메모리를 많이 쓰고 있었다는 것을 확인했다.
12:10 에 statuspage.io 로 해결을 발표한 뒤에도 조사를 이어갔다. 13:00 에 새로 적용한 LimitRange 때문에 Grafana Agent 가 여전히 내려가 있는 것을 발견했다. 13:49 에는 Hangfire 로 작업을 실행하는 개발 컨테이너가 OOM 으로 실패하고, OOM 이 날 때마다 CrashLoopBackOff 를 반복하고 있었다는 결론을 냈다. 13:55 에 이 개발 컨테이너가 쓰는 RDS 인스턴스에서 문제를 찾았고, EC2 네트워크 트래픽이 늘어난 것이 RDS, 개발 컨테이너와 맞물려 있다는 것도 찾았다.
개발 컨테이너를 0개로 줄이자 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다. 그런데 원래대로 3개로 되돌리자 15:03 에 새로 띄운 노드가 NotReady 가 되어 Slack 알림이 다시 왔다.
10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.
포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.
IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 애플리케이션 데이터베이스, 컨테이너 메모리 한도
IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다Blue Matador · 2019같은 원인 · 공통 컨테이너 메모리 한도, 텔레메트리 에이전트
IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 컨테이너 메모리 한도
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 컨테이너 메모리 한도
IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.UK Ministry of Justice · 2024같은 원인 · 공통 텔레메트리 에이전트
IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다Saifeddine Rajhi · 2024같은 원인 · 공통 컨테이너 메모리 한도
IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.Scaleway · 2024같은 원인 · 공통 컨테이너 메모리 한도
IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 텔레메트리 에이전트
IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다UK Ministry of Justice · 2023같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.Palark · 2023같은 원인 · 공통 텔레메트리 에이전트
IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.2i2c · 2020같은 원인 · 공통 컨테이너 메모리 한도
IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 애플리케이션 데이터베이스
IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 애플리케이션 데이터베이스
IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.Civis Analytics · 2019같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 컨테이너 메모리 한도