问题现象

在Kubernetes集群运维中，当CoreDNS出现异常时，通常表现为集群内Pod无法通过服务名解析其他Service的IP地址，应用日志中频繁出现connection refused或no such host错误，而使用IP地址访问却正常。此类故障会直接影响微服务间的相互调用，需要快速定位并处理。

故障排查步骤

1. 检查CoreDNS Pod运行状态

首先确认CoreDNS的Pod是否处于Running状态，并查看是否有异常重启记录。

• kubectl -n kube-system get pods -l k8s-app=kube-dns
• 若Pod状态为CrashLoopBackOff或长时间处于Pending，则需要进一步查看描述信息：kubectl -n kube-system describe pod

2. 查看CoreDNS日志

通过日志分析异常原因，常见的错误包括配置错误、网络插件冲突或资源限制。

• kubectl -n kube-system logs --tail=200 -l k8s-app=kube-dns
• 关注日志中的timeout、connection refused、plugin/loop等关键字。

3. 验证CoreDNS服务与DNS配置

• 查看Service是否存在端点：kubectl -n kube-system get endpoints kube-dns
• 检查Pod内的resolv.conf是否指向正确的CoreDNS ClusterIP，并确认没有指向外部不可达DNS。
• 使用nslookup或dig命令在一个测试Pod中进行解析验证，区分是CoreDNS本身故障还是网络链路问题。

常见原因分析

• 资源不足：CoreDNS Pod的CPU或内存配额过低，遇到高并发解析请求时触发OOM或被驱逐。
• 配置错误：CoreDNS配置文件（Corefile）被手动修改过，例如使用了错误的转发目标或启用了不兼容的插件。
• 节点问题：CoreDNS所在节点出现内存压力或网络异常，导致Pod健康检查失败。
• iptables规则异常：kube-proxy生成的iptables规则被破坏或nat表冲突，导致流量无法正确转发到CoreDNS。

重启修复与运维操作

1. 强制删除异常Pod触发重建

当CoreDNS Pod状态异常但控制器为Deployment时，可以直接删除Pod使其重建。

• kubectl -n kube-system delete pod -l k8s-app=kube-dns
• 重建后观察Pod是否正常进入Running状态，并检查重启次数是否归零。

2. 如果删除后依然异常，则扩容副本进行滚动更新

• 当前默认副本数通常为2，可临时扩容至3个以分散压力：kubectl -n kube-system scale deployment coredns --replicas=3
• 观察新Pod是否正常，若原Pod仍异常，可进一步删除异常的Pod触发重新调度。

3. 检查并修正CoreDNS配置

使用kubectl -n kube-system edit configmap coredns检查Corefile内容，确保forward指向的上级DNS（如10.96.0.10）正确，且没有配置循环转发。修改后需重启CoreDNS使配置生效。

4. 清理无效网络规则（必要时）

如确认是iptables问题，可在CoreDNS所在节点上临时检查并重建规则，但需谨慎操作，建议在业务低峰期进行。更稳妥的方式是重启kube-proxy或相关节点组件。

验证恢复效果

• 在任意工作负载Pod中执行nslookup kubernetes.default.svc.cluster.local，确认返回正确的ClusterIP。
• 测试其他Pod之间通过Service名称互联，检查业务日志中是否不再有DNS解析错误。
• 观察CoreDNS的QPS与错误率，确认资源使用率恢复正常。

预防建议

• 为CoreDNS设置合理的资源请求与限制，避免因资源争抢导致异常。
• 监控CoreDNS的关键指标（如请求数、5xx错误率、缓存命中率），并配置告警。
• 避免直接修改生产环境Corefile，如需调整应通过CI/CD流程或配置版本管理。
• 定期检查集群DNS相关的iptables规则与网络插件状态，防止底层链路失效。

CoreDNS作为集群内部DNS解析的核心组件，一旦异常会迅速影响全局服务通信。运维人员应熟练掌握上述排查与重启修复流程，同时建立完善的监控和应急响应机制，确保能够快速恢复服务并降低故障影响。