企业官网建设流程全解析

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

Kubernetes 里很多“偶发超时”最后都会指向 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 --image=busybox:1.36 -- sh nslookup kubernetes.default.svc.cluster.local nslookup api.example.com kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide kubectl -n kube-system logs deploy/coredns --tail=100

如果只有某个节点上的 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 是服务发现的地基。把指标、日志、抓包和应用行为串起来，才能把“偶发超时”从玄学变成可定位的问题。