{"id":"IL-0104","org":"Cisco ThousandEyes","date":"2025-09-04","docs":["https://github.com/kubernetes/kubernetes/issues/126130"],"title":{"en":"After a CoreDNS pod was OOMKilled, the talk names three causes: Istio's aggressive DNS cache refresh on one reused client port, kube-proxy not cleaning up conntrack entries of terminated pods, and the 2-minute UDP conntrack timeout","ko":"Istio 의 공격적인 DNS 캐시 갱신과 클라이언트 포트 재사용, kube-proxy 가 종료된 파드의 conntrack 항목을 정리하지 않는 문제, 2분짜리 UDP conntrack 기본 타임아웃이 겹쳐 CoreDNS 파드가 OOMKilled 됐다."},"domain":["kubernetes","networking"],"impact":{"scope":"unknown","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The closing slide sets three behaviours side by side: Istio's extremely aggressive DNS cache refresh with one client port reused for all DNS requests, kube-proxy's lack of a cleanup mechanism for stale conntrack entries of terminated pods (fixed in Kubernetes v1.32), and conntrack's default bidirectional UDP stream timeout of 2 minutes. The speaker describes Istio as making some very complex things simple but some very simple things complex, and presents Cilium, which looks up Services in maps instead of walking the KUBE-SERVICES chain and can replace kube-proxy entirely with its eBPF data path.","ko":"장애는 Istio, kube-proxy, conntrack 각각의 동작이 겹쳐 생겼다. Istio 는 DNS 캐시를 공격적으로 갱신하며 클라이언트 포트를 다시 썼고, kube-proxy 는 conntrack 항목을 정리하지 않았고, conntrack 의 UDP 기본 타임아웃은 2분이었다. kube-proxy 쪽 문제는 쿠버네티스 v1.32 에서 고쳐졌다. 발표자는 Istio 가 아주 복잡한 일은 단순하게 만들지만 아주 단순한 일은 복잡하게 만든다고 평했다. 발표자는 또 Cilium 을 소개했다. Cilium 은 iptables 체인을 차례로 훑는 대신 맵으로 Service 를 찾고, eBPF 데이터 경로로 kube-proxy 를 완전히 대체할 수 있다."},"related":[],"sources":[{"url":"https://www.usenix.org/conference/srecon26americas/presentation/bejarano","kind":"talk","license":"unknown","archived":null}],"summary":{"en":"The talk walks through how a pod resolves a name and reaches a Service: getaddrinfo, then the KUBE-SERVICES, KUBE-SVC and KUBE-SEP iptables chains that kube-proxy writes, and conntrack, which records connection state so that packets of a known connection skip full iptables evaluation. The cluster ran Istio in sidecar mode, with Istio ServiceEntries, and the interval at which Istio refreshes its DNS cache is hard-coded.\n\nThe final slide names three causes, one each under Istio, kube-proxy and conntrack. Istio has an extremely aggressive DNS cache refresh and reuses the same client port for all DNS requests. kube-proxy had no mechanism to clean up stale conntrack entries for terminated pods; this is Kubernetes issue #126130, fixed in v1.32. conntrack's default timeout for a bidirectional UDP stream is 2 minutes.","ko":"Cisco ThousandEyes 의 리드 SRE 가 SREcon26 Americas 에서 발표한 사례다. 2025년 9월 4일 CoreDNS 파드 하나가 OOMKilled 됐다. 이 클러스터는 kube-proxy 가 만드는 KUBE-SERVICES, KUBE-SVC, KUBE-SEP iptables 체인으로 Service 트래픽을 파드에 보내고, 서비스 메시로 Istio 를 사이드카 모드로 쓴다. conntrack 은 이미 본 패킷으로 연결 상태를 기억해, 알려진 연결의 패킷은 iptables 규칙을 다시 평가하지 않고 같은 곳으로 보낸다.\n\n발표는 원인을 셋으로 정리한다. 첫째, Istio 는 DNS 캐시를 매우 공격적으로 갱신하고 모든 DNS 요청에 같은 클라이언트 포트를 다시 쓴다. 이 갱신 간격은 코드에 고정돼 있다. 둘째, kube-proxy 에는 종료된 파드의 오래된 conntrack 항목을 정리하는 장치가 없었다. 이 문제는 쿠버네티스 이슈 #126130 에서 다뤄졌고 v1.32 에서 고쳐졌다. 셋째, conntrack 의 양방향 UDP 스트림 기본 타임아웃은 2분이다."},"trigger":{"en":"A CoreDNS pod was OOMKilled.","ko":"CoreDNS 파드 하나가 OOMKilled 됐다."},"severity":"unknown","symptoms":["dns-resolution-failures","stale-service-routing","oom-killed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["coredns","kube-proxy","conntrack","istio"],"root_cause":"software-bug","remediation":[],"action_items":[],"contributing":["default-config-unchanged"],"recurrence_of":null,"symptoms_text":{"en":"On 4 September 2025 a CoreDNS pod in a Cisco ThousandEyes Kubernetes cluster was OOMKilled.","ko":"2025년 9월 4일, CoreDNS 파드 하나가 OOMKilled 됐다."},"updated_at":"2026-11-09T11:55:44.874275Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0104","org_slug":"cisco-thousandeyes"}