第一步需验证CoreDNS健康状态：检查Pod是否Running且READY为1/1，查看日志中的plugin/errors、timeout等错误，确认CPU/Memory限制合理，避免OOMKilled或请求排队。
确认CoreDNS是否正常运行
解析失败或超时，第一步要验证CoreDNS本身是否健康。检查Pod状态、日志和资源限制是否合理：
- 执行 kubectl get pods -n kube-system -l k8s-app=kube-dns，确认CoreDNS Pod处于 Running 状态，且 READY 列为 1/1
- 查看日志：kubectl logs -n kube-system deployment/coredns，重点关注 plugin/errors、timeout、refused 或反复出现的 no upstream
- 检查CPU/Memory限制是否过低（尤其在高并发解析场景），导致请求排队或被OOMKilled —— 可通过 kubectl describe pod -n kube-system coredns-xxx 查看事件和资源状况
验证集群内DNS配置与服务发现路径
CoreDNS依赖正确配置的Service和Endpoints才能解析集群内服务（如 myservice.default.svc.cluster.local）：
- 确认 kube-dns Service存在且ClusterIP可访问：kubectl get svc -n kube-system kube-dns，并用 curl -v http://
:53 （需用telnet或dig测试UDP 53更准确） - 检查对应Endpoints：kubectl get endpoints -n kube-system kube-dns，确保有匹配的CoreDNS Pod IP；若为空，说明Service selector未匹配到Pod（常见于标签变更或部署异常）
- 验证Pod的 /etc/resolv.conf 是否指向CoreDNS：进入业务Pod执行 cat /etc/resolv.conf，确认 nameserver 是 10.96.0.10（默认kube-dns ClusterIP）且 search 域包含 default.svc.cluster.local 等
使用dig/tcpping定位解析卡点环节
在业务Pod中直接测试，区分是DNS查询超时，还是后端服务不可达：
- 查集群内服务：dig myservice.default.svc.cluster.local @10.96.0.10 +short，若无响应或超时，说明CoreDNS未返回结果；若返回IP但业务连不通，则是网络或服务问题
- 查外部域名（如 google.com）：dig google.com @10.96.0.10 +short，若失败，检查CoreDNS是否配置了上游DNS（如 forward . 8.8.8.8），并在ConfigMap中确认 Corefile 无语法错误
- 用 tcping -x 5 10.96.0.10 53 或 nc -zv 10.96.0.10 53 测试DNS端口连通性，排除网络策略（NetworkPolicy）、kube-proxy异常或iptables规则拦截
检查CoreDNS配置与插件行为
ConfigMap中的Corefile决定解析逻辑，常见疏漏点包括：
- 转发配置缺失或错误：确认 forward 插件是否启用，例如 forward . 1.1.1.1 8.8.8.8；若只配了一个上游且该地址不可达，会整体超时，建议配至少两个
- hosts插件干扰：若自定义了 hosts 或 template 插件，检查是否有误匹配或死循环重写
- 缓存设置不合理：开启 cache 插件可缓解上游压力，但若 maxttl 过小或缓存击穿严重，也可能加剧延迟；临时可注释 cache 行测试是否改善
- 修改后务必重启CoreDNS：kubectl rollout restart deployment/coredns -n kube-system，并等待新Pod Ready
结合节点网络与CNI排查底层连通性
即使CoreDNS本身正常，节点或CNI插件异常也会导致DNS请求发不出或收不到响应：
- 在Node上执行 dig @127.0.0.1 -p 1053 google.com（假设CoreDNS以hostNetwork模式监听本地53端口），验证节点层面DNS可达性
- 检查CNI插件状态（如Calico/Flannel/Cilium）：kubectl get pods -n kube-system | grep -i calico，确认所有组件Running；若使用Calico，注意 FelixConfiguration 中是否禁用了DNS相关策略
- 抓包辅助判断：tcpdump -i cni0 port 53 -w dns.pcap（在业务Pod所在Node上），看请求是否发出、应答是否返回，明确是出向丢包还是回包丢失
