IL-0182 이언철 · 2024-04-16 (게시일)kubernetesaws
글쓴이의 EKS 클러스터에서는 트래픽이 급변할 때 CoreDNS 에 부하가 몰려 네트워크 문제와 지연 급증이 생겼다. HPA 가 파드를 늘리면서 데이터베이스 커넥션이 급증했고, 영향은 서비스 전체로 번졌다. 요청이 들어올 때 동작하는 작업용 파드들은 CoreDNS 수가 모자라 네트워크가 간헐적으로 끊겼다.
글쓴이는 먼저 세 가지를 적용했다. 첫째, 클러스터 크기에 맞춰 CoreDNS 를 늘리는 Cluster Proportional Autoscaler 를 설정했다. CPA 라고 부르는 이 도구에 인스턴스 타입에 맞는 nodesPerReplica 와 coresPerReplica 를 정하고, 모니터링하며 replica 최솟값과 최댓값을 조정했다. 둘째, CoreDNS 에 anti-affinity 대신 topologySpreadConstraints 를 걸고 ScheduleAnyway 로 제약을 느슨하게 해 Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다. 이는 Karpenter 가 권하는 방식이다. CoreDNS EKS 애드온은 v1.9.3-eksbuild.11 과 v1.10.1-eksbuild.7 부터 topologySpreadConstraints 를 기본값으로 넣는다. 셋째, CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 만들었다.
이렇게 운영하던 중 CoreDNS replica 를 과하게 늘린 것이 새 문제를 낳았다. 모든 노드에 taint 가 있어 CoreDNS 가 특정 노드에만 몰렸다. maxSkew 1 을 지키려다 노드마다 CoreDNS 파드가 3~4개씩 생겼고, 이 노드들은 Consolidation 되지 못했다. 글쓴이는 메인 CoreDNS 의 부하 자체를 낮추려고 NodeLocal DNSCache 를 적용했다. 노드마다 DaemonSet 으로 뜬 로컬 CoreDNS 가 DNS 캐시 역할을 하고, 그 노드의 파드는 모두 로컬 CoreDNS 에 질의한다. 로컬 CoreDNS 는 캐시에서 답하거나 질의를 메인 CoreDNS 로 넘긴다. 적용 뒤 운영 지표가 크게 나아졌고, 노드가 Consolidation 되지 못해 과하게 늘어나던 문제도 풀렸다.
트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.
지연이 늘자 HPA 가 파드를 늘렸고, 늘어난 파드가 데이터베이스 커넥션을 급격히 늘렸다. 문제는 서비스 전체로 번졌다. 요청이 들어올 때 뜨는 작업용 파드들은 노드를 유연하게 쓰는 구조였는데, 수가 적은 CoreDNS 가 이들을 감당하지 못했다. 이 파드들은 네트워크가 간헐적으로 끊겨 제대로 동작하지 못했다.
글쓴이는 CoreDNS 를 클러스터 크기에 맞춰 늘리는 Cluster Proportional Autoscaler 인 CPA, topologySpreadConstraints, 알림 조건을 적용해 운영하다가 새 문제를 발견했다. 안정성을 위해 CoreDNS replica 를 지나치게 늘린 것이 문제였다. 모든 노드에 taint 가 걸려 있어서 Deployment 로 띄운 CoreDNS 는 default 같은 특정 노드에만 떴다. topologySpreadConstraints 의 maxSkew 1 을 지키려다 노드 하나에 CoreDNS 파드가 3~4개씩 생겼고, 그 노드들은 Karpenter 의 노드 통합 기능인 Consolidation 으로 정리되지 못했다. 노드는 필요 이상으로 늘어난 채 남았다.
–
–
CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다.
IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026같은 원인 · 공통 CoreDNS, 수평 파드 오토스케일러
IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다DigitalOcean · 2026같은 원인 · 공통 CoreDNS
같은 원인 · 공통 수평 파드 오토스케일러
같은 원인 · 공통 파드 스케줄링과 배치
IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.unknown · 2025같은 원인 · 공통 CoreDNS
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 CoreDNS
IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.Render · 2024같은 원인 · 공통 CoreDNS
같은 원인 · 공통 Karpenter
IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 파드 스케줄링과 배치
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 파드 스케줄링과 배치