CoreDNS 是 Kubernetes 集群内部的服务发现核心组件，所有 Pod 之间的相互调用几乎都依赖它完成域名解析。一旦 CoreDNS 出现异常，表现往往是 Pod 内访问 Service 名称失败，报出 Name or service not known 或者 i/o timeout 这类错误。排查这类问题时不能一上来就重启 CoreDNS，正确的做法是先确认故障范围，再沿着解析链路逐段定位。
一、先确认故障范围：是全局故障还是个别Pod的问题
排查的第一步是搞清楚影响面。如果整个集群所有 Pod 都无法解析域名，那问题大概率出在 CoreDNS 本身、kube-dns Service 或者网络插件上；如果只有个别 Pod 解析失败，则更可能是该 Pod 的 DNS 配置、所在节点的 iptables/IPVS 规则或者上游 DNS 出了问题。
可以随便找一个业务 Pod 或者临时启动一个测试 Pod 来验证：
kubectl run dns-test --rm -it --image=busybox:1.36 -- /bin/sh # 进入容器后执行 nslookup kubernetes.default nslookup kube-dns.kube-system.svc.cluster.local ping 223.5.5.5
如果解析 kubernetes.default 失败但 ping 223.5.5.5 通畅，说明容器网络本身没问题，故障集中在 DNS 链路；如果外网 IP 也不通，就要优先排查 CNI 网络插件，比如 Calico、Flannel 的 Pod 是否正常。另外建议多找几个节点上的 Pod 测试，如果故障只集中在某几个节点，基本可以锁定是节点层面的 kube-proxy 或网络规则问题。
二、检查CoreDNS自身的运行状态和Service配置
确认是 DNS 问题后，下一步看 CoreDNS 是否活着。执行以下命令：
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide kubectl get svc -n kube-system kube-dns kubectl top pods -n kube-dns -l k8s-app=kube-dns
重点观察 Pod 是否处于 Running 状态、READY 列是否为 1/1、重启次数是否异常增长。如果 Pod 频繁 CrashLoopBackOff，需要看日志和退出原因：
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 kubectl describe pod <coredns-pod-name> -n kube-system
常见的一种崩溃场景是 Corefile 配置写错了，比如 plugin 链顺序不对或者引用了不存在的插件，日志里会直接给出解析 Corefile 失败的提示。另一种情况是 CoreDNS 内存被 OOMKill，当集群规模大、QPS 高时，CoreDNS 默认的内存 limit 可能不够，可以在Prometheus里观察 coredns_dns_request_size_bytes 等指标，适当调大资源限额并增加副本数。
接着确认 kube-dns Service 的 ClusterIP 是否正常。检查 Service 的 Endpoints 是否包含所有 CoreDNS Pod 的 IP，如果 Endpoints 为空，通常是标签选择器不匹配或者 CoreDNS Pod 未通过就绪探针。还要留意 CoreDNS 的 Deployment 是否配置了 clusterIP 冲突或 Service 端口被改动的情形，这些都会造成解析请求根本到不了 CoreDNS。
三、从Pod视角验证解析链路：resolv.conf与ndots陷阱
CoreDNS 正常不代表解析一定成功，请求能否正确送达还要看 Pod 的 DNS 配置。先看一下 Pod 的 resolv.conf 内容：
cat /etc/resolv.conf # 典型输出 search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5
nameserver 指向的应该就是 kube-dns Service 的 ClusterIP，如果不一致，说明 kubelet 启动参数 --cluster-dns 配错了。重点说说 ndots:5 这个经典陷阱：域名中点数少于5时会先依次拼接 search domain 尝试解析，全部失败后才走绝对域名查询。这意味着访问一个外部短域名（比如 myapp.com）时，Pod 会先向 CoreDNS 发起多次无意义的集群内查询，一次外网请求实际上放大成了四五次 DNS 查询。在高并发场景下这会显著拖慢解析甚至触发超时。
排查时可以在测试 Pod 中对比带尾部点号的查询：
nslookup myapp.com nslookup myapp.com. # 对比两者耗时，如果前者明显慢，就是 search domain 放大问题
解决方案有几种：对于访问外部域名频繁的应用，可以在 Deployment 中指定 dnsConfig 把 ndots 调成 1 或者 2；也可以启用 NodeLocal DNSCache，在每个节点上跑一个本地缓存 Pod，通过 DaemonSet 以 169.254.20.10 这样的链路本地地址提供缓存，既减少 CoreDNS 压力，也大幅降低查询延迟，是生产环境非常推荐的做法。
四、深入定位：用dig分析转发与上游DNS问题
如果集群内部域名（*.svc.cluster.local）能解析而外部域名失败，问题基本锁定在 CoreDNS 的上游转发配置。Corefile 中 forward 插件指向的 DNS 服务器不可达、被防火墙拦截或者响应过慢，都会导致外网域名解析超时。可以在节点上直接测试上游：
dig @<上游DNS IP> www.baidu.com +time=2 +tries=1
进入 CoreDNS 容器或者用 debug 容器查看实际生效的 Corefile：
kubectl exec -n kube-system <coredns-pod> -- cat /etc/coredns/Corefile # 典型转发配置 # forward . /etc/resolv.conf
当 forward 使用 /etc/resolv.conf 时，CoreDNS 会继承所在节点的 DNS 配置，如果节点本身 DNS 指向的是内网 DNS 且无法解析公网域名，就会出现上述症状。此外还要关注 UDP 1032 字节以上的大报文问题：某些网络环境会截断超过 1500 字节的 UDP 包，导致响应偶尔丢失，表现为解析“时好时坏”。解决办法是在 Corefile 的 forward 插件后加上参数强制 TCP 或者确保网络支持分片。
最后，如果所有手段都查不出问题，别忘了看 conntrack 表和 kube-proxy 模式。IPVS 模式下 conntrack 条目耗尽、某些内核版本的 UDP 连接复用 bug，都会造成 DNS 偶发丢包。观察 conntrack -S 的 drop 和 insert_failed 计数，如果持续增长，说明需要调整 conntrack 参数或者升级内核。定位到根因后再做针对性修复，比盲目重启 CoreDNS 有效得多。
CoreDNSKubernetes域名解析kubectl debug修改时间：2026-09-04 03:54:44