coredns频繁重启主因是宿主机/etc/resolv.conf缺失、为空或含127.0.0.53等不可达dns，致forward插件初始化panic；需检查并修复该文件，禁用systemd-resolved或改用/run/systemd/resolve/resolv.conf。
CoreDNS不断重启，基本就是启动失败后被kubelet反复拉起，根本原因通常不是配置写错了，而是它根本没机会读到配置——宿主机的/etc/resolv.conf缺失、内容为空或含不可达地址（比如127.0.0.53），导致forward插件初始化直接panic。
检查宿主机/etc/resolv.conf是否可用
CoreDNS容器默认以hostPath方式挂载宿主机的/etc/resolv.conf，并依赖其中的nameserver行做上游转发。如果该文件不存在、为空、或只含127.0.0.53（Ubuntu systemd-resolved 本地代理），CoreDNS会报no nameservers found然后崩溃。
- 登录任意工作节点，运行：
cat /etc/resolv.conf - 若输出为空或只有
search行，说明NetworkManager未生成有效DNS；临时修复可手动追加：echo "nameserver 8.8.8.8" >> /etc/resolv.conf - 若含
nameserver 127.0.0.53，需禁用systemd-resolved或改用/run/systemd/resolve/resolv.conf（后者才含真实上游） - 永久解决：编辑
/etc/NetworkManager/NetworkManager.conf，在[main]下加dns=none，再执行systemctl restart NetworkManager
验证CoreDNS ConfigMap中forward配置是否合法
即使/etc/resolv.conf存在，CoreDNS仍可能因Corefile语法错误或插件冲突而panic。常见雷区是升级后残留的proxy插件，或rewrite参数顺序错乱。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 运行：
kubectl get configmap coredns -n kube-system -o yaml，确认Corefile字段存在且非空 - 检查
forward . /etc/resolv.conf是否写成proxy . /etc/resolv.conf（1.8+已废弃proxy） - 确认没有在同一
server块里同时出现proxy和forward - 若用
rewrite，确保语法符合CoreDNS 1.10+规范，例如rewrite name substring example.com example.internal而非旧版rewrite stop name example.com example.internal
排查CNI网络插件导致的Pod沙箱创建失败
当CoreDNS卡在ContainerCreating而非CrashLoopBackOff时，问题不在CoreDNS本身，而在CNI无法为其分配网络。典型日志是networkPlugin cni failed to setup pod ... no configuration has been provided或cni0 already has an IP address。
- 先确认CNI插件（如flannel、calico）的DaemonSet是否正常运行：
kubectl get ds -n kube-system - 检查节点上CNI配置文件是否存在：
ls /etc/cni/net.d/，应有类似10-flannel.conflist的文件 - 若曾执行过
kubeadm reset，需手动清理残留：ip link delete cni0、ip link delete flannel.1、iptables -F - 重启kubelet：
systemctl restart kubelet，再观察kubectl describe pod -n kube-system coredns-xxx里的Events
确认资源限制是否触发OOMKilled
CoreDNS内存用量低，但若集群规模大、查询量高，或配置了大量重写规则，仍可能因内存超限被cgroup kill。此时Pod状态为Running但频繁重启，kubectl describe里会出现OOMKilled事件。
- 查事件：
kubectl describe pod -n kube-system coredns-xxx | grep -A5 Events - 看容器实际内存使用：
kubectl top pod -n kube-system coredns-xxx - 若CPU/内存持续偏高，考虑调高limits：
kubectl edit deployment coredns -n kube-system，在containers.resources.limits下增加memory: "256Mi" - 更治本：启用NodeLocal DNSCache，分流本地查询，减少CoreDNS压力
真正棘手的是/etc/resolv.conf问题——它不报错在CoreDNS日志里，而是在容器启动前就被kubelet拒绝挂载，导致你看到的永远是“找不到文件”或“no nameservers”，却想不到去查宿主机。每次节点重启、NetworkManager重载配置，都可能让它悄悄消失一次。
