{"id":"IL-0182","org":"이언철","date":"2024-04-16","docs":["https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/"],"title":{"en":"Too few CoreDNS replicas on EKS were overloaded during traffic spikes, raising latency and cutting the network for task pods, and the over-provisioned, tightly spread CoreDNS pods added later blocked Karpenter consolidation","ko":"트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다"},"domain":["kubernetes","aws"],"impact":{"scope":"the whole service: higher latency, a surge in database connections, and request-driven task pods that intermittently lost network and did not work properly","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A fixed, small number of CoreDNS pods cannot follow a cluster whose nodes and pods change quickly with traffic, and the damage spreads: DNS latency triggers autoscaling, which in turn floods the database with connections. Simply adding many CoreDNS replicas created a different problem, because with tainted nodes and a maxSkew: 1 spread constraint the pods piled onto a few nodes and blocked Karpenter consolidation. Scaling CoreDNS in proportion to the cluster and putting a DNS cache on every node handled both.","ko":"CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다."},"related":[],"sources":[{"url":"https://velog.io/@yieon/CoreDNS-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"The author, a DevOps engineer, describes CoreDNS problems on an Amazon EKS cluster that uses Karpenter. Under fast-changing traffic, too few CoreDNS pods handled the DNS load: latency rose, the network dropped intermittently for task pods, and the horizontal pod autoscaler's scale-out drove a surge in database connections that spread the impact across the service.\n\nThe first round of fixes sized CoreDNS to its capacity and made it scale with the cluster. The author notes that each CoreDNS pod needs a certain amount of resources and that average latency and queries per second depend on how much each pod can handle. The team set up the Cluster Proportional Autoscaler (CPA), which scales CoreDNS by cluster size, choosing nodesPerReplica and coresPerReplica for the instance types in use and tuning the replica minimum and maximum through monitoring. They spread CoreDNS with topologySpreadConstraints instead of anti-affinity, as Karpenter suggests, using the soft ScheduleAnyway setting so Karpenter could still consolidate and replace nodes for drift; EKS add-on versions v1.9.3-eksbuild.11 and v1.10.1-eksbuild.7 and later include topologySpreadConstraints by default. They also set alert thresholds on CoreDNS error rate, panics, request duration and request rate, and in New Relic used a Prometheus agent to integrate kube-dns with an agent status dashboard.\n\nThe over-provisioned CoreDNS pods then piled up 3 to 4 per node on the few nodes they could run on, and those nodes could not be consolidated. To take load off the main CoreDNS, the team deployed NodeLocal DNSCache, a CoreDNS DaemonSet on every node that answers from its cache or forwards to the main CoreDNS. DNS query volume to the main CoreDNS fell sharply, spikes became easier to absorb, and a DNS problem now stays on one node instead of spreading to the whole service. After this change the production metrics improved considerably and the node over-expansion stopped. The author concludes that CPA together with NodeLocal DNSCache resolved the CoreDNS load problem.","ko":"글쓴이의 EKS 클러스터에서는 트래픽이 급변할 때 CoreDNS 에 부하가 몰려 네트워크 문제와 지연 급증이 생겼다. HPA 가 파드를 늘리면서 데이터베이스 커넥션이 급증했고, 영향은 서비스 전체로 번졌다. 요청이 들어올 때 동작하는 작업용 파드들은 CoreDNS 수가 모자라 네트워크가 간헐적으로 끊겼다.\n\n글쓴이는 먼저 세 가지를 적용했다. 첫째, 클러스터 크기에 맞춰 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 에 임곗값 알림을 만들었다.\n\n이렇게 운영하던 중 CoreDNS replica 를 과하게 늘린 것이 새 문제를 낳았다. 모든 노드에 taint 가 있어 CoreDNS 가 특정 노드에만 몰렸다. maxSkew 1 을 지키려다 노드마다 CoreDNS 파드가 3~4개씩 생겼고, 이 노드들은 Consolidation 되지 못했다. 글쓴이는 메인 CoreDNS 의 부하 자체를 낮추려고 NodeLocal DNSCache 를 적용했다. 노드마다 DaemonSet 으로 뜬 로컬 CoreDNS 가 DNS 캐시 역할을 하고, 그 노드의 파드는 모두 로컬 CoreDNS 에 질의한다. 로컬 CoreDNS 는 캐시에서 답하거나 질의를 메인 CoreDNS 로 넘긴다. 적용 뒤 운영 지표가 크게 나아졌고, 노드가 Consolidation 되지 못해 과하게 늘어나던 문제도 풀렸다."},"trigger":{"en":"Sharp changes in traffic loaded the small number of CoreDNS pods beyond what they could handle.","ko":"트래픽이 급변하면서 수가 적은 CoreDNS 파드에 처리할 수 있는 양보다 많은 부하가 몰렸다."},"severity":"unknown","symptoms":["high-latency","intermittent-connection-failures","autoscaler-misbehaving"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["coredns","karpenter","hpa","pod-scheduling"],"root_cause":"capacity","remediation":[{"text":{"en":"Set up the Cluster Proportional Autoscaler for CoreDNS with nodesPerReplica and coresPerReplica chosen for the instance types in use","ko":"클러스터 크기에 맞춰 CoreDNS replica 를 늘리도록 CPA 를 설정하고, 인스턴스 타입에 맞게 nodesPerReplica, coresPerReplica, replica 최솟값과 최댓값을 조정했다."}},{"text":{"en":"Spread CoreDNS with soft topologySpreadConstraints (ScheduleAnyway) instead of anti-affinity so Karpenter could consolidate nodes","ko":"CoreDNS 에 anti-affinity 대신 ScheduleAnyway 로 느슨하게 한 topologySpreadConstraints 를 걸어, Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다."}},{"text":{"en":"Added alert thresholds on CoreDNS error rate, panics, request duration and request rate","ko":"CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 걸었다."}},{"text":{"en":"Deployed NodeLocal DNSCache so each node answers DNS from a local cache and forwards misses to the main CoreDNS","ko":"NodeLocal DNSCache 를 적용해 노드마다 DNS 캐시를 두고 메인 CoreDNS 의 부하를 낮췄다."}}],"action_items":[],"contributing":["automation-amplified","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"When traffic changed sharply, CoreDNS came under heavy load, and the cluster saw network problems and a sudden rise in latency. The horizontal pod autoscaler then added pods, database connections surged, and the impact spread to the whole service.\n\nTask pods, which start when a request comes in, ran on nodes that come and go. The small number of CoreDNS pods could not keep up with them, so the network dropped intermittently and these pods did not work properly.\n\nAfter the first fixes, a second problem appeared. CoreDNS replicas had been raised well beyond need for stability. Every node carried a taint, so the CoreDNS Deployment's pods landed only on particular nodes (for example the default ones), and to keep topologySpreadConstraints maxSkew: 1 the scheduler placed 3 to 4 CoreDNS pods per node. Those nodes could not be consolidated, and the node count grew too large.","ko":"트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.\n\n지연이 늘자 HPA 가 파드를 늘렸고, 늘어난 파드가 데이터베이스 커넥션을 급격히 늘렸다. 문제는 서비스 전체로 번졌다. 요청이 들어올 때 뜨는 작업용 파드들은 노드를 유연하게 쓰는 구조였는데, 수가 적은 CoreDNS 가 이들을 감당하지 못했다. 이 파드들은 네트워크가 간헐적으로 끊겨 제대로 동작하지 못했다.\n\n글쓴이는 CoreDNS 를 클러스터 크기에 맞춰 늘리는 Cluster Proportional Autoscaler 인 CPA, topologySpreadConstraints, 알림 조건을 적용해 운영하다가 새 문제를 발견했다. 안정성을 위해 CoreDNS replica 를 지나치게 늘린 것이 문제였다. 모든 노드에 taint 가 걸려 있어서 Deployment 로 띄운 CoreDNS 는 default 같은 특정 노드에만 떴다. topologySpreadConstraints 의 maxSkew 1 을 지키려다 노드 하나에 CoreDNS 파드가 3~4개씩 생겼고, 그 노드들은 Karpenter 의 노드 통합 기능인 Consolidation 으로 정리되지 못했다. 노드는 필요 이상으로 늘어난 채 남았다."},"updated_at":"2026-11-09T11:55:56.972596Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0182","org_slug":"이언철"}