CoreDNS pod CrashLoopBackOff 显示 “plugin/forward: no healthy upstream”

Coredns因无法连接上游DNS服务器导致“no healthy upstream”错误，常见原因包括节点/etc/resolv.conf配置不可达、ConfigMap配置错误、网络策略拦截、本地DNS服务干扰或资源不足。

dns 的默认上游，通常是宿主机的 /etc/resolv.conf 中配置的 nameserver）导致的典型错误。Pod 启动后 forward 插件找不到可用的上游，健康检查失败，反复重启。

检查 CoredNS 配置中的 upstream 是否可达

CoreDNS 默认使用 forward . /etc/resolv.conf（或类似），实际会读取该文件内容作为上游。但容器内挂载的 /etc/resolv.conf 往往继承自节点——如果节点本身 DNS 不通（比如防火墙拦截、上游 nameserver 不响应、或配置了不可达 IP 如 169.254.20.10），CoreDNS 就会报 “no healthy upstream”。

• 进一个正常运行的 Pod（如 busybox），执行 nslookup kubernetes.default 或 dig @10.96.0.10 google.com（假设 CoreDNS ClusterIP 是 10.96.0.10），确认集群 DNS 是否能解析外部域名
• 在节点上运行 cat /etc/resolv.conf，看 nameserver 是否合理（避免出现 127.0.0.53 或已下线的内部 DNS 地址）
• 在节点上用 dig @ google.com 测试该 upstream 是否真实可达

确认 CoreDNS ConfigMap 是否被意外修改

CoreDNS 的行为由 coredns ConfigMap 控制（通常在 kube-system 命名空间）。常见问题包括：

• 手动编辑时误删或写错 forward 行，例如写成 forward . 8.8.8.8 但没加端口，或用了不支持的语法
• 把 forward . /etc/resolv.conf 改成了指向一个未监听 udp 53 的服务（如只开了 TCP，或端口不对）
• 启用了 health 插件但未正确配置健康检查路径，导致 readiness probe 失败连带影响 forward 判定

建议恢复为标准配置（Kubernetes 官方推荐）：

forward . /etc/resolv.conf

排查网络插件或节点级 DNS 策略干扰

某些 CNI 插件（如 Calico、Cilium）或安全策略（NetworkPolicy、ebpf 规则、iptables DNAT）可能拦截或重定向 DNS 请求，尤其是目标端口 53 的 UDP 流量。

• 检查节点是否运行了本地 DNS 缓存（如 systemd-resolved、dnsmasq），并确认其监听地址是否被 CoreDNS 容器正确继承
• 临时关闭节点防火墙（systemctl stop firewalld 或 ufw disable）测试是否缓解
• 在 CoreDNS 容器中执行 nc -zv 53（UDP 不支持 nc 检测，改用 timeout 2 dig @ google.com +short）验证连通性

验证 CoreDNS 是否因资源不足或启动顺序异常失败

虽不直接触发该报错，但低内存限制（memory: 170Mi 是底线）、或 initContainer 抢占 DNS 解析时机，也可能导致 forward 初始化失败。

• 查看 Pod 事件：kubectl -n kube-system describe pod ，关注 Warning 级事件（如 FailedCreatePodSandBox、OOMKilled）
• 检查资源请求是否过低：kubectl -n kube-system get deploy coredns -o yaml | grep -A 5 resources
• 确认 coredns Deployment 的 dnsPolicy 是 Default（非 ClusterFirst），否则它会试图用自己解析自己，形成死锁