Pod 之间无法通过域名解析通信怎么排查 CoreDNS 配置

Pod 之间无法通过域名解析通信，通常是因为 CoreDNS 服务异常、网络策略拦截或 Pod DNS 配置错误，优先检查 CoreDNS 状态和集群网络策略。

先说结论：大多数解析故障源于 CoreDNS Pod 不可用、安全组拦截 53 端口或 Pod 的 dnsPolicy 配置不当，按顺序排查可快速定位。

先确认：CoreDNS Pod 是否处于 Running 状态且无重启
先处理：放行 VPC 安全组 UDP 53 端口，检查 NetworkPolicy
再验证：在测试 Pod 内使用 nslookup 确认解析恢复

命令速用版

# 1. 检查 CoreDNS 是否运行
kubectl get pods -l k8s-app=kube-dns -n kube-system

# 2. 查看 CoreDNS 日志
kubectl logs -l k8s-app=kube-dns -n kube-system

# 3. 进入 Pod 检查 DNS 配置
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# 4. 测试解析
kubectl exec -it <pod-name> -- nslookup kubernetes.default

为什么会这样

Kubernetes 集群内，Pod 默认将 DNS 请求发送到 kube-system 命名空间中的 CoreDNS 服务。如果 CoreDNS 本身宕机、负载过高，或者网络层面（如 VPC 安全组、NetworkPolicy）拦截了 UDP 53 端口，请求就无法到达 DNS 服务器。此外，Pod 的 dnsPolicy 配置决定了它如何使用 resolv.conf，若配置为 Default 或 None 且未指定 nameserver，也可能导致无法解析集群内部域名。

分步处理

1. 确认 CoreDNS 组件状态
首先检查 kube-system 命名空间下的 CoreDNS Pod 是否正常运行。如果 Pod 处于 CrashLoopBackOff 或 Pending 状态，解析必然失败。查看日志中是否有权限错误或配置加载失败的报错。

2. 检查 Pod 内部 DNS 配置
进入业务 Pod，查看/etc/resolv.conf 文件。正常情况下，nameserver 应指向 ClusterIP 范围的 DNS 服务地址。如果文件未被 CoreDNS 修改，可能是 kubelet 配置或 CoreDNS 工作异常。

3. 排查网络策略与安全组
检查集群使用的安全组规则，确保放开了 UDP 协议的 53 端口。若使用了 NetworkPolicy，确认未隐性阻断 Pod 到 CoreDNS 的通信。某些 VPC 环境下的主机防火墙也可能丢弃 DNS 流量。

4. 检查 CoreDNS 配置项
查看 kube-system 下的 coredns ConfigMap，确认 forward 插件配置的上游 DNS 是否可达。若配置了 loop 插件，需防止递归解析死循环；若服务数量过大，需关注 cache 和并发设置。

怎么验证是否生效

创建一个临时测试 Pod，确保它与故障 Pod 在同一命名空间或网络策略允许范围内。在测试 Pod 内执行 nslookup 命令解析集群内部服务域名（如 kubernetes.default）和外部域名（如 www.baidu.com）。若两者均能返回 IP 地址，且延迟正常，说明解析链路已恢复。

常见坑

1. hostNetwork 导致失效
若 Pod 使用了 hostNetwork: true，它将直接使用节点网络的 DNS 配置，可能无法解析集群内部 Service 域名，需手动调整 dnsPolicy。

2. 安全组拦截 UDP
部分云环境默认安全组规则较严，可能仅放行 TCP 而拦截 UDP 53 端口，导致 DNS 查询超时。

3. 上游 DNS 不可达
CoreDNS 依赖节点的上游 DNS 解析外部域名，若节点 resolv.conf 配置的内网 DNS 不可用，会导致外部域名解析失败但内部正常。

参考来源

诊断与排查 DNS 解析异常的常见原因与解决方案 - 容器服务 Kubernetes 版 ACK - 阿里云帮助中心
从 Pod 内部进行 DNS 解析故障排查 - Azure | Microsoft Learn
Kubernetes Pod DNS 异常排查与 CoreDNS 策略优化实战
K8S 集群中 Coredns 域名解析故障排查思路
CoreDNS 报错排查指南