CoreDNS因无法连接上游DNS服务器导致“no healthy upstream”错误，常见原因包括节点/etc/resolv.conf配置不可达、ConfigMap配置错误、网络策略拦截、本地DNS服务干扰或资源不足。
这是 CoreDNS 无法连接到上游 DNS 服务器（比如 kube-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 @<nameserver> google.com测试该 upstream 是否真实可达
确认 CoreDNS ConfigMap 是否被意外修改
CoreDNS 的行为由 coredns ConfigMap 控制（通常在 kube-system 命名空间）。常见问题包括：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 手动编辑时误删或写错
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 <upstream-ip> 53（UDP 不支持 nc 检测，改用timeout 2 dig @<ip> google.com +short）验证连通性
验证 CoreDNS 是否因资源不足或启动顺序异常失败
虽不直接触发该报错，但低内存限制（memory: 170Mi 是底线）、或 initContainer 抢占 DNS 解析时机，也可能导致 forward 初始化失败。
- 查看 Pod 事件：
kubectl -n kube-system describe pod <coredns-pod-name>，关注 Warning 级事件（如 FailedCreatePodSandBox、OOMKilled） - 检查资源请求是否过低：
kubectl -n kube-system get deploy coredns -o yaml | grep -A 5 resources - 确认
corednsDeployment 的dnsPolicy是Default（非ClusterFirst），否则它会试图用自己解析自己，形成死锁
