排查定位
集群内 DNS 解析失败的表现通常是应用报 name resolution 错误、连不上另一个 Service。适用平台是 Kubernetes，名字解析由 kube-system 里的 CoreDNS（旧集群是 kube-dns）承担：Pod 的 /etc/resolv.conf 指向 kube-dns Service，CoreDNS 依据 Service 与 EndpointSlice 生成记录，集群外域名再转发给上游 DNS。定位顺序应该是「先看 Pod 的解析配置，再看 CoreDNS 是否健康，最后看上游转发」，而不是一上来重启组件。
基本信息
| 适用平台 | Kubernetes，DNS 由 CoreDNS 提供（kube-dns Service 为入口） |
|---|---|
| Pod 侧配置 | /etc/resolv.conf 的 nameserver、search、ndots 由 kubelet 按集群 DNS 配置注入 |
| 记录形式 | <service>.<ns>.svc.cluster.local，Pod 级记录仅 Headless Service 才有 |
| 权限要求 | 能读 kube-system 下的 Pod、Service、ConfigMap |
典型使用场景
- 应用报连不上下游服务：先区分是 DNS 解析失败还是解析成功但连接被拒
- 新命名空间部署后名字解析不了：确认 Service 是否创建、名字是否写错命名空间
- 外部域名解析失败：集群内名字正常，说明问题在上游转发或 CoreDNS 的 forward 配置
- 间歇性超时：怀疑 ndots 触发多次查询或上游不稳定，用临时 Pod 反复验证
- 排查 NodeLocal DNSCache 引入的变化：部署后解析走本机缓存，排查点跟着变
三步定位
三步定位
kubectl run dnsutils --rm -it --restart=Never --image=registry.k8s.io/e2e-test-images/agnhost:2.45 -- nslookup kubernetes.default
kubectl get pods -n kube-system -l k8s-app=kube-dns # CoreDNS 副本是否齐全
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50 # 看 SERVFAIL、超时与上游报错
kubectl get svc -n kube-system kube-dns # 入口 Service 与端口
kubectl exec -it web-x -- cat /etc/resolv.conf # 故障 Pod 自己的解析配置
kubectl get endpoints kube-dns -n kube-system # DNS 自身有没有可用后端现象与原因对照
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| 集群内名字解析失败，外部正常 | Service 不存在或命名空间写错 | 核对 svc 名与 FQDN |
| 全部名字都失败 | CoreDNS 副本全挂或 kube-dns Service 无端点 | 看副本数、重启次数与端点 |
| 只有外部域名失败 | CoreDNS forward 指向的上游不通 | 查 CoreDNS ConfigMap 的 forward 配置与节点出网 |
| 偶发超时 | ndots 触发多轮查询或上游抖动 | 观察 resolv.conf 的 ndots 与 search |
| 某个 Pod 单独失败 | 该 Pod 的 dnsPolicy 或 dnsConfig 被改写 | 对比正常 Pod 的解析配置 |
resolv.conf 里的 ndots 与 search 决定解析路径：ndots 默认为 5，域名里的点少于该值时先拼 search 后缀逐个尝试，这就是「解析慢但最终成功」的常见来源。
排查时在故障 Pod 与新建临时 Pod 上各测一次，可以快速区分是个例（该 Pod 的配置或网络策略问题）还是集群级问题（CoreDNS 或上游）。
重启 CoreDNS 期间集群内所有新解析都会受影响，排障应先取证（日志、端点、副本状态）再考虑重启，避免现场被清掉。