Kubernetes 生产排障：DNS 抖动时别只重启 CoreDNS

Kubernetes 生产排障DNS 抖动时别只重启 CoreDNSKubernetes 里很多“偶发超时”最后都会指向 DNS服务发现慢、外部域名解析失败、Pod 启动后第一波请求超时。新人排障常见操作是重启 CoreDNS运气好能缓解运气不好只是把证据清空。DNS 抖动不是一个点的问题它可能来自 CoreDNS、NodeLocal DNSCache、节点网络、上游 DNS、conntrack 或应用解析行为。生产排障别急着拍脑袋先把链路拆开。一、DNS 查询链路要画出来flowchart LR A[Pod] -- B[/etc/resolv.conf] B -- C[Cluster DNS Service] C -- D[CoreDNS Pod] D -- E[NodeLocal DNSCache] D -- F[Upstream DNS] A -- G[Application Resolver]不同集群架构不一样有的直接 Pod 到 CoreDNS有的启用了 NodeLocal DNSCache。链路不清楚抓包都不知道抓哪里。二、先看现象范围DNS 问题要先判断是单 Pod、单节点、单命名空间、全集群还是只影响外部域名。kubectl run dns-debug --rm -it --imagebusybox:1.36 -- sh nslookup kubernetes.default.svc.cluster.local nslookup api.example.com kubectl -n kube-system get pod -l k8s-appkube-dns -o wide kubectl -n kube-system logs deploy/coredns --tail100如果只有某个节点上的 Pod 异常优先查节点网络、iptables、conntrack 和 NodeLocal DNSCache。全局异常再看 CoreDNS 和上游。三、CoreDNS 指标比重启有用CoreDNS 有 Prometheus 指标延迟、错误、缓存命中、转发失败都能看到。重启前先采集证据。sum(rate(coredns_dns_requests_total[5m])) by (type) sum(rate(coredns_dns_responses_total{rcode!NOERROR}[5m])) by (rcode) histogram_quantile(0.99, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le)) sum(rate(coredns_forward_request_duration_seconds_count[5m])) by (to)如果SERVFAIL升高可能是上游问题如果 p99 延迟高但错误不多可能是负载或网络抖动如果缓存命中低可能是查询模式不合理。四、应用侧解析行为也会制造压力有些应用每次请求都解析域名不做连接复用有些语言运行时 DNS 缓存策略很激进或完全不缓存还有些服务把短 TTL 域名放进高频路径。app_dns_checklist ├── connection pool enabled ├── resolver cache policy known ├── ndots value reviewed ├── search domain expansion controlled └── external DNS not queried in hot loop尤其要看/etc/resolv.conf里的ndots。配置不合理时一个外部域名可能先被拼接多个 search domain产生额外查询。五、总结Kubernetes DNS 抖动排障别一上来重启 CoreDNS。先判断影响范围再按 Pod、节点、CoreDNS、NodeLocal、上游 DNS 和应用解析行为逐层排查。DNS 是服务发现的地基。把指标、日志、抓包和应用行为串起来才能把“偶发超时”从玄学变成可定位的问题。