CoreDNS 1.8.0 镜像下载失败通常是因为镜像仓库地址变更或网络问题，最直接的解决方式是从 Docker Hub 拉取后重新打标签，或切换为国内可用的镜像源。
先说结论：CoreDNS 1.8.0 在部分镜像仓库中确实存在缺失情况，尤其是阿里云的 google_containers 仓库，建议从 Docker Hub 拉取官方镜像后本地打标签使用。
- 先确认：检查当前集群版本对应的 CoreDNS 镜像地址和版本号
- 先处理：从 Docker Hub 拉取 coredns/coredns:1.8.0 后通过 docker tag 重命名
- 再验证：执行 kubeadm init 或检查 kube-system 命名空间下 CoreDNS Pod 状态
命令速用版
如果是在初始化集群阶段遇到镜像拉取失败，可以先手动拉取并打标签：
# 从 Docker Hub 拉取 CoreDNS 1.8.0 镜像
docker pull coredns/coredns:1.8.0
# 根据 kubeadm 要求的镜像地址打标签（以阿里云仓库为例）
docker tag coredns/coredns:1.8.0 registry.aliyuncs.com/google_containers/coredns:v1.8.0
# 如果使用的是 k8s.gcr.io 地址
docker tag coredns/coredns:1.8.0 k8s.gcr.io/coredns/coredns:v1.8.0
# 查看 kubeadm 需要的镜像列表
kubeadm config images list `--kubernetes-version`=v1.21.3如果集群已初始化但 CoreDNS Pod 状态异常，检查 Pod 日志和节点 DNS 配置：
# 查看 CoreDNS Pod 状态
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 查看 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns
# 检查节点/etc/resolv.conf 配置
cat /etc/resolv.conf为什么会这样
CoreDNS 镜像下载失败主要有两类原因。第一类是镜像仓库问题，某些镜像仓库（如阿里云的 google_containers 仓库）在特定时期没有同步 CoreDNS 1.8.0 版本，这是因为 CoreDNS 项目在版本迭代过程中镜像命名和仓库地址有过调整。第二类是节点 DNS 配置问题，CoreDNS Pod 启动时会读取宿主机的/etc/resolv.conf 文件，如果该文件中没有有效的 nameserver 配置，CoreDNS 会因无法转发外部 DNS 请求而启动失败。
另外，kubeadm init 命令在初始化时会按照指定版本拉取一组系统镜像，如果其中任何一个镜像拉取失败，初始化过程就会卡住。CoreDNS 作为 Kubernetes 1.13 版本之后的默认 DNS 服务器，是集群服务发现的核心组件，缺少它集群内部域名解析将无法正常工作。
分步处理
步骤一：确认需要的镜像版本
先查看当前 Kubernetes 版本对应的 CoreDNS 镜像地址和标签：
kubeadm config images list `--kubernetes-version`=v1.21.3记录输出中 CoreDNS 的完整镜像地址，例如 registry.aliyuncs.com/google_containers/coredns:v1.8.0 或 k8s.gcr.io/coredns/coredns:v1.8.0。
步骤二：从可用源拉取镜像
如果默认仓库拉取失败，从 Docker Hub 拉取官方镜像：
docker pull coredns/coredns:1.8.0拉取成功后，使用 docker tag 命令将镜像重命名为 kubeadm 期望的地址。
步骤三：处理节点 DNS 配置问题
如果镜像已存在但 CoreDNS Pod 仍无法启动，检查宿主机 DNS 配置：
cat /etc/resolv.conf如果文件中没有 nameserver 条目，需要配置有效的 DNS 服务器。为防止重启后配置丢失，可以编辑 NetworkManager 配置文件：
vi /etc/NetworkManager/NetworkManager.conf在 [main] 段落下添加 dns=none，然后重启 NetworkManager 服务。
步骤四：重新初始化或重启 Pod
如果是在 kubeadm init 阶段，镜像准备好后重新执行初始化命令。如果集群已运行但 CoreDNS Pod 异常，可以删除 Pod 让其重新调度：
kubectl delete pod -n kube-system -l k8s-app=kube-dns怎么验证是否生效
镜像问题解决后，通过以下方式验证：
# 检查 CoreDNS Pod 是否处于 Running 状态
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 查看 Pod 是否有重启记录
kubectl describe pod -n kube-system -l k8s-app=kube-dns
# 测试集群内部域名解析
nslookup kubernetes.default
nslookup cluster.local如果 Pod 状态为 Running 且 READY 列为 1/1，说明 CoreDNS 已正常工作。可以在集群内创建一个测试 Pod 验证外部域名解析是否可用。
常见坑
- 镜像地址不匹配：docker tag 时目标地址必须与 kubeadm config images list 输出的完全一致，包括仓库路径和标签格式
- 节点重启后 DNS 配置丢失：/etc/resolv.conf 可能被 NetworkManager 覆盖，建议通过 NetworkManager 配置文件持久化设置
- CoreDNS 配置中 forward 指向无效 DNS：CoreDNS 的 Corefile 配置中 forward 插件会读取宿主机的/etc/resolv.conf，如果宿主机 DNS 不可用，CoreDNS 也无法转发外部请求
- 多节点集群镜像不同步：如果集群有多个节点，需要在所有节点上执行镜像拉取和打标签操作，否则 Pod 调度到缺少镜像的节点时会失败
- 版本对应关系：不同 Kubernetes 版本需要的 CoreDNS 版本不同，不要随意使用其他版本的 CoreDNS 镜像，可能导致兼容性问题
参考来源
- 进击的 davis - 博客园，《k8s 部署问题记录-v1.21.3》，记录了阿里云仓库缺少 CoreDNS 1.8.0 镜像及从 Docker Hub 拉取后打标签的解决方案
- K8S 故障处理指南，《coredns 状态异常处理记录》，2024 年 1 月 14 日，记录了服务器重启后 CoreDNS 因/etc/resolv.conf 配置问题导致启动失败的排查方法
- 《Kubernetes 网络之 CoreDNS》，2024 年 12 月 19 日，说明 CoreDNS 自 Kubernetes 1.13 版本起成为默认 DNS 服务器
- 《K8S CoreDNS 部署失败，问题分析》，2019 年 8 月 17 日，记录了物理机 DNS 配置错误导致 CoreDNS 解析失败的案例
原文链接：https://www.zjcp.cc/ask/10462.html