{"id":"IL-0033","org":"Airbnb","date":"2019-11-21","docs":[],"title":{"en":"Uneven load across kube-dns pods and a DNS packets-per-second limit pushed service latency to 20 seconds","ko":"kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다"},"domain":["kubernetes","aws","networking"],"impact":{"scope":"multiple services that made many external DNS queries","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"By default a pod discovers DNS through the kube-dns cluster IP and uses the ClusterFirst policy, so even external lookups go through kube-dns. If a pod does not need cluster DNS, set its dnsPolicy to Default or None. Check the DNS policy early and often.\n\niptables picks backends at random and is not a load balancer, so pods behind a cluster IP, kube-dns included, can carry very different loads.","ko":"기본 설정에서 파드는 클러스터 IP 로 DNS 서버를 찾고, dnsPolicy 기본값인 ClusterFirst 때문에 외부 이름 조회도 kube-dns 를 먼저 거친다. 쿠버네티스 DNS 해석이 필요 없는 파드는 dnsPolicy 를 Default 로 두거나, None 으로 두고 세부 값을 직접 정할 수 있다. iptables 는 로드 밸런서가 아니어서 클러스터 IP 뒤의 파드에 부하를 고르게 나누지 못한다. 발표자들은 DNS 정책을 초기부터 자주 확인하고 용도에 맞는 정책을 쓰라고 했다."},"related":[],"sources":[{"url":"https://www.youtube.com/watch?v=QXApVwRBeys","kind":"talk","license":"unknown","archived":null}],"summary":{"en":"Airbnb ran Kubernetes on AWS EC2 with Ubuntu images and the Canal CNI plugin (Calico with flannel), and was moving services that used to run on their own EC2 instances onto Kubernetes and containers; by September 2019 about a thousand services ran on Kubernetes. In this talk two Airbnb engineers go through latency problems that showed up during the migration.\n\nPods use the dnsPolicy ClusterFirst by default, so every DNS query, including queries for names outside the cluster, is sent to kube-dns through its cluster IP. That cluster IP is implemented with iptables rules, which pick a kube-dns pod at random rather than balancing load, so some kube-dns pods received far more queries than others. The team then hit a DNS packets-per-second limit, and DNS responses slowed down and timed out. The affected services all relied heavily on DNS and made many external lookups. Service latency rose from around one second to five and then 20 seconds across several services.\n\nThe speakers' answer is to choose the DNS policy per pod: a pod that does not need Kubernetes DNS resolution can use dnsPolicy Default, or None with its own DNS parameters, so that its external lookups do not pass through kube-dns.","ko":"Airbnb 는 EC2 인스턴스에서 따로 돌던 서비스를 쿠버네티스와 컨테이너로 옮기고 있었다. 운영 이전은 2018년 초에 본격적으로 시작했고 2019년 9월에는 쿠버네티스에서 도는 서비스가 약 천 개였다. 발표는 이전 과정에서 나온 성능 문제 여러 건을 다루며, 이 사례는 그중 kube-dns 가 느려진 건이다.\n\n파드의 DNS 요청은 iptables 를 거쳐 kube-dns 의 클러스터 IP 로 가고, iptables 는 kube-dns 파드 가운데 하나를 무작위로 고른다. 무작위 선택은 부하를 고르게 나누지 못해서 일부 kube-dns 파드에 트래픽이 몰렸다. 그 결과 DNS 초당 패킷 한도에 걸렸고, 여러 서비스에서 응답이 느려지고 타임아웃이 났다.\n\n파드의 기본 DNS 정책은 ClusterFirst 다. 그래서 클러스터 안의 서비스 주소가 아닌 외부 이름을 조회할 때도 질의가 먼저 kube-dns 를 거친다. 영향받은 서비스들은 모두 DNS 에 크게 의존하고 외부 DNS 조회를 많이 하는 서비스였다."},"trigger":{"en":"Several services sent a high volume of external DNS queries, all of which went through kube-dns.","ko":"여러 서비스가 외부 DNS 조회를 많이 보냈고, 그 질의가 모두 kube-dns 를 거쳤다."},"severity":"unknown","symptoms":["high-latency","intermittent-timeouts","uneven-load","dns-resolution-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Latency graphs of several services showed the rise; engineers then looked at load per kube-dns pod.","ko":"문제는 서비스의 지연 시간 그래프에서 처음 드러났다. 같은 모양이 여러 서비스에서 나타나자 팀은 공통점을 찾았고, kube-dns 파드별 질의량을 비교해 불균형을 찾아냈다."},"components":["kube-dns","kube-proxy","dns-resolver"],"root_cause":"capacity","remediation":[],"action_items":[],"contributing":["default-config-unchanged"],"recurrence_of":null,"symptoms_text":{"en":"On May 10 the latency graphs of several services showed a few spikes of up to about one second, then latency climbed to five seconds and then to 20 seconds, and it stayed there for a long time. The same pattern appeared on many services, not just one.\n\nThe affected services had one thing in common: they relied heavily on DNS and sent many DNS queries for names outside the cluster. The query load on kube-dns was uneven: some kube-dns pods were handling a high rate of queries per second while others handled very little. DNS answers became slow and timed out for several services.","ko":"한 서비스의 지연 시간 그래프에 5월 10일부터 스파이크가 보이기 시작했다. 처음에는 1초 안팎까지 튀었고, 이어서 5초, 다시 20초로 올라간 뒤 꽤 오랫동안 그 수준에 머물렀다.\n\n한 서비스만의 일이 아니었다. 여러 서비스의 그래프에서 지연 시간이 올라갔다. 영향받은 서비스들의 공통점은 DNS 에 크게 의존하고 외부 DNS 조회를 많이 한다는 것이었다.\n\n팀이 kube-dns 부하를 들여다보니 어떤 kube-dns 파드는 초당 질의 수가 꽤 높았고 어떤 파드는 낮았다. kube-dns 파드 사이에 트래픽이 고르게 나뉘지 않았다."},"updated_at":"2026-11-08T19:10:28.917651Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0033","org_slug":"airbnb"}