Kubernetes内网DNS异常排查需分层验证：先检查Pod的resolv.conf配置及内部/外部域名解析能力，再验证CoreDNS Pod状态、Service/Endpoint连通性、日志错误与Corefile upstream配置，最后通过直连CoreDNS Pod隔离数据面问题；若启用NodeLocal DNSCache，还需确认节点resolv.conf指向169.254.20.10并确保其Pod正常运行。
排查 Kubernetes 内网 DNS 异常，核心是分层验证：先确认 Pod 自身 DNS 配置是否合理，再验证 CoreDNS 服务是否健康、可连通，最后区分是 CoreDNS 自身故障，还是转发链路或上游问题。
检查 Pod 的 DNS 配置和基础解析能力
进入异常 Pod（如 kubectl exec -it <pod-name> -- sh），执行以下操作：
- 运行
cat /etc/resolv.conf，确认nameserver指向集群 DNS Service IP（通常是10.96.0.10），而非宿主机地址（如127.0.0.53）或空；search域应含svc.cluster.local等标准后缀。 - 执行
nslookup kubernetes.default.svc.cluster.local：成功说明内部服务域名可解析，CoreDNS 基本工作正常；失败则问题在 CoreDNS 本身或 Service/Endpoint 层。 - 执行
nslookup google.com：若内部能通、外部不通，大概率是 upstream DNS 不可达，或 NodeLocal DNSCache 配置未生效。
验证 CoreDNS 组件状态与配置
在控制节点执行以下命令：
-
kubectl get pods -n kube-system -l k8s-app=kube-dns：确保所有 CoreDNS Pod 处于Running且Ready状态。 -
kubectl get svc,endpoint -n kube-system kube-dns：检查 Endpoint 列出的 IP 是否与 CoreDNS Pod 实际 IP 一致，端口（53/UDP 和 TCP）映射是否正确。 -
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100：关注i/o timeout（上游超时）、forward plugin: no upstream（Corefile 缺失 forward 配置）、Failed to watch（API 权限或连接异常）等关键错误。 -
kubectl get cm coredns -n kube-system -o yaml：检查Corefile中forward插件是否配置了有效上游（如8.8.8.8或 VPC 内 DNS 地址），避免写成forward . /etc/resolv.conf但宿主机 resolv.conf 不可用。
隔离数据面，直连 CoreDNS Pod 测试
绕过 Service VIP，排除 kube-proxy 或 IPVS 转发异常干扰：
- 获取一个 CoreDNS Pod IP：
kubectl get pod -n kube-system -l k8s-app=kube-dns -o wide | awk '{print $6}' | head -1 - 在业务 Pod 中直接查询：
nslookup kubernetes.default <coredns-pod-ip> - 若直连成功但通过 Service 失败，说明问题在 Service、Endpoint 或网络策略（如 NetworkPolicy 拦截了 53 端口）；若直连也失败，则聚焦 CoreDNS Pod 自身（资源不足、OOMKilled、挂载失败等）。
检查 NodeLocal DNSCache（如已启用）
若集群启用了 NodeLocal DNSCache，需额外确认：
- 各节点
/etc/resolv.conf中nameserver应为169.254.20.10（默认地址），而非集群 DNS IP 或宿主机 DNS。 - 运行
kubectl get pods -n kube-system -l k8s-app=node-local-dns，确保所有节点上该 Pod 正常运行。 - 重启异常节点上的 node-local-dns Pod：
kubectl delete pod -n kube-system -l k8s-app=node-local-dns --field-selector spec.nodeName=<node-name>，触发重建。
