IL-0027 Backpackr · 2025-05-07 (게시일)kubernetesawsnetworking
백패커는 아이디어스를 운영하는 EKS 클러스터를 처음 구성할 때 CoreDNS 를 따로 최적화하지 않고 기본 설정 그대로 두었다. CoreDNS 파드는 2개였고, nodeSelector 로 온디맨드 타입의 운영 노드 그룹에만 배치했다. CoreDNS 파드에는 메모리 한도가 없어서 QoS 클래스가 BestEffort 였다.
쿠버네티스는 모든 파드의 /etc/resolv.conf 에 ndots:5 를 넣는다. 리졸버는 점이 다섯 개보다 적은 이름을 불완전한 이름으로 보고 검색 도메인을 하나씩 붙여 먼저 조회한다. 그 조회가 모두 실패한 뒤에야 원래 이름으로 조회한다. 그래서 idus.com 을 한 번 호출하면 idus.com.idus-backends.svc.cluster.local, idus.com.svc.cluster.local, idus.com.cluster.local, idus.com.ap-northeast-2.compute.internal, idus.com 순서로 최대 다섯 번 조회가 나갔고 마지막 조회만 성공했다. 트래픽이 급증하면 이 불필요한 조회가 고스란히 CoreDNS 에 몰렸다.
고가용성 설정도 없었다. 당시 EKS 버전의 CoreDNS 에는 PodDisruptionBudget 과 topologySpreadConstraints 가 기본으로 들어 있지 않았다. 어느 시점에 CoreDNS 파드가 모두 한 노드에 올라갔고, 그 노드의 메모리가 고갈되어 OOM 이 났다. kubelet 이 멈추면서 노드의 파드가 모두 CrashLoopBackOff 에 빠졌고, DNS 가 응답하지 않자 서비스 전체가 멈췄다.
백패커는 NodeLocalDNS Cache 를 도입하고, CoreDNS 에 고가용성 설정을 넣고, 워크로드의 ndots 를 2 로 낮춰 CoreDNS 부하를 나누었다. 도메인 끝에 점을 붙여 FQDN 으로 조회하는 방법은 모든 도메인 참조를 고쳐야 해서 유지보수가 어렵다고 보고 쓰지 않았다. Istio DNS 프록시도 검토했지만 NodeLocalDNS Cache 와 기능이 겹쳐 쓰지 않았다.
프로덕션 EKS 클러스터에서 원인을 바로 알기 어려운 서비스 에러가 간헐적으로 났다. RDS 나 Redis 같은 외부 서비스를 호출할 때 연결이 가끔 실패했다. DNS 요청이 몰릴 때는 도메인 조회 응답이 늦어지거나 조회가 아예 실패했다.
이 증상은 트래픽이 적은 개발 환경과 스테이징 환경에서는 잘 보이지 않았고, 트래픽이 큰 프로덕션 환경에서 두드러졌다.
팀은 처음에 애플리케이션 코드, 노드 리소스, 파드 상태, 컨테이너 설정을 차례로 점검했다. 자세히 조사한 끝에 외부 서비스 연결 실패의 근본 원인이 DNS 이름 해석 실패라는 것을 확인했다. 그다음 CoreDNS 의 캐시 설정과 bufsize 를 조정해 봤지만 증상이 잠깐 줄었을 뿐 근본 해결이 되지 않았다.
어느 시점에는 CoreDNS 파드가 모두 한 노드에 몰려 있었다. 그 노드의 메모리 사용률이 갑자기 치솟았고 노드에서 OOM 이 났다. kubelet 이 멈추면서 그 노드의 모든 파드가 CrashLoopBackOff 에 빠졌다. CoreDNS 도 응답하지 못했고 서비스 전체가 멈췄다.
글은 전면 장애를 어떻게 알아챘는지 적지 않았다. 그 전의 DNS 문제는 원인을 알기 어려운 서비스 에러가 간헐적으로 나면서 드러났다. 팀은 RDS 와 Redis 호출이 가끔 실패하는 현상을 추적하다가 DNS 이름 해석 실패가 근본 원인이라는 것을 확인했다.
–
쿠버네티스의 ndots:5 기본값은 점이 적은 외부 도메인을 조회할 때마다 질의를 여러 번 만든다. 이 부하는 트래픽이 큰 프로덕션 환경에서야 드러난다. CoreDNS 를 파드 2개의 기본 구성으로 두면 클러스터 전체의 단일 장애점이 된다. CoreDNS 파드는 노드와 가용 영역에 흩어 둔다. 별도 노드 그룹이나 Fargate 로 분리하면 다른 워크로드와 자원을 다투지 않는다. Affinity 와 PriorityClassName 으로 우선순위를 주면 더 안정적이다. CoreDNS 의 캐시와 bufsize 조정은 증상을 잠깐 줄였을 뿐이다. ndots 값은 여러 자료가 1이나 2를 권하지만 각 환경에 맞춰 정해야 한다.
IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026같은 원인 · 공통 노드 풀, 컨테이너 메모리 한도, CoreDNS
같은 원인 · 공통 컨테이너 메모리 한도, 클라이언트 쪽 DNS 리졸버와 캐시, CoreDNS
IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다DigitalOcean · 2026같은 원인 · 공통 노드 풀, CoreDNS
IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.unknown · 2025같은 원인 · 공통 클라이언트 쪽 DNS 리졸버와 캐시, CoreDNS
IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.RebelMouse · 2025같은 원인 · 공통 노드 풀, CoreDNS
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 노드 풀, 컨테이너 메모리 한도
IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.Scaleway · 2024같은 원인 · 공통 컨테이너 메모리 한도, kubelet
IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다UK Ministry of Justice · 2023같은 원인 · 공통 노드 풀, 컨테이너 메모리 한도
IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.2i2c · 2020같은 원인 · 공통 노드 풀, 컨테이너 메모리 한도
IL-0071 작은 파일이 4만 개 넘게 든 단일 스테이지 이미지의 containerd 스냅샷이 쌓여 워커 노드의 inode 가 디스크보다 빠르게 소진되고 있었다Onkar Raghunath Shelke · 2026같은 원인 · 공통 kubelet
같은 원인 · 공통 노드 풀
IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.Render · 2024같은 원인 · 공통 CoreDNS
IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다Saifeddine Rajhi · 2024같은 원인 · 공통 컨테이너 메모리 한도
IL-0182 트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다이언철 · 2024같은 원인 · 공통 CoreDNS
IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다2i2c · 2023같은 원인 · 공통 노드 풀
IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 컨테이너 메모리 한도
IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.LINE · 2020같은 원인 · 공통 kubelet
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
IL-0033 kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다Airbnb · 2019같은 원인 · 공통 클라이언트 쪽 DNS 리졸버와 캐시
IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다Blue Matador · 2019같은 원인 · 공통 컨테이너 메모리 한도