CoreDNS v1.8.0离线包安装指南：从tar.gz到集群DNS

简介：这是coredns v1.8.0的Docker镜像离线包，专为Kubernetes v1.21.2集群环境准备，适用于需要在内网或离线场景下部署、升级CoreDNS组件的运维人员与K8s学习者。包体整体为gz压缩格式，共包含8个文件，其中tar文件保存实际镜像层数据，json文件记录镜像配置与manifest清单，version文件标明组件版本，整体大小约40.62MB，结构精简、易于校验。目前已有405人学习下载，适用于离线安装、私有仓库导入或集群初始化时快速加载DNS组件。通过这份资源，读者可以直接获得经过验证的coredns v1.8.0镜像及其元数据，免去外网拉取或手工构造镜像的麻烦，同时还能参考VERSION与JSON配置加深对Docker镜像分层结构及K8s组件离线交付方式的理解，对搭建高可用K8s集群有一定实用价值。

1. 从 tar.gz 到可用 DNS：CoreDNS v1.8.0 离线包怎么装才不翻车

在隔离网段里装过 Kubernetes 的人都懂，集群起来了，Pod 也调度上了，结果业务 Pod 之间用 Service 域名互相访问超时，一查发现 CoreDNS 一直 CrashLoopBackOff。你手上没有内网镜像仓库，外网又拉不了 registry.k8s.io 的镜像，这时coredns_v1.8.0.tar.gz这种离线包就成了救命稻草。它不是源码，不是文档，而是把 CoreDNS v1.8.0 容器镜像打包好的产物，一条导入命令就能让集群 DNS 跑起来。适合做离线交付的运维、自建集群的开发者，以及刚接手 K8s 环境、被 DNS 解析折腾过的同学。这篇文章会把选型逻辑、导入路径、Corefile 配置和现场踩过的坑一次性讲透。

2. 为什么是 v1.8.0：选型逻辑与 K8s 版本兼容边界

2.1 CoreDNS 在 K8s 里的角色：没有它 Service 域名全废

Kubernetes 集群内的服务发现不依赖注册中心，而是靠 DNS。每个 Service 会生成一条服务名.命名空间.svc.cluster.local的记录，Pod 里发起请求时，先把这个域名解析成 ClusterIP，再走 kube-proxy 转发。这套机制从 kube-dns 时代就有了，CoreDNS 是后来接替 kube-dns 的组件，用 Go 写的，插件化架构，性能更好，配置也更灵活。

v1.8.0 是 2021 年发布的版本，K8s 1.21 到 1.23 时代的默认配套。它最核心的插件是 kubernetes、forward、hosts 和 cache。kubernetes 插件负责同步 Service 和 Endpoint 的记录；forward 把非集群域名的查询转发给上游 DNS；hosts 让你能写死自定义域名映射；cache 做本地缓存，减少对上游的重复查询。这套机制决定了 Pod 里/etc/resolv.conf的 nameserver 指向 CoreDNS 的 ClusterIP，你改掉 Corefile，整个集群的解析策略就变了。

离线包能解决的核心问题，是你没有内网镜像仓库时，手动把镜像导入集群节点就能拉起 Deployment。它和在线安装的区别只在于镜像来源不同，配置和排错逻辑完全一致。所以下文所有步骤都以「本地导入镜像 + 修改 ConfigMap」为主线，不依赖任何云厂商托管服务。

2.2 兼容性判断：v1.8.0 适合哪些 K8s 版本

拿到离线包先别急着导，先确认这个版本和你的集群匹配。CoreDNS 的版本不是随意搭配的，不同 K8s 版本对默认 DNS 组件版本有对应关系。v1.8.0 官方适配范围是 K8s 1.18 到 1.23，尤其是 1.21 系列，基本是开箱即用的状态。K8s 1.24 之后，Pod 的priorityClass、PodSecurity 和容器运行时默认行为都变了，1.8.0 依然能跑，但你需要额外处理 probe 的httpGet配置，否则就绪探针可能误判。

如果你的集群是 1.24 以上，我一般会先看 kubelet 的--cluster-dns参数，再把 CoreDNS 的 ClusterIP 对上去。版本不匹配最常见的现象是 CoreDNS 能启动，但日志刷 schema 不兼容或解析结果异常，这时候优先怀疑版本，不要盲目改配置。

提示：离线环境下把coredns_v1.8.0.tar.gz导入后，务必用docker image inspect或ctr images list确认镜像 tag 是coredns/coredns:v1.8.0，不要被文件名误导成其他格式。

3. 离线落地全流程：解压、导镜像、改配置三步走

3.1 预检：先看清楚包里有什么

拿到coredns_v1.8.0.tar.gz，先确认包结构。有的压缩包直接是 docker save 产物，有的里面还带了部署清单和说明文档。用 tar 看下清单：

tar -tzvf coredns_v1.8.0.tar.gz | head -20

参数说明：-t列出内容，-z解压 gzip，-v显示详细信息，-f指定文件名。head -20只取前 20 行，避免镜像层多的时候刷屏。执行后的输出里如果直接看到coredns.tar或coredns_v1.8.0.tar这种嵌套 tar，需要先解出内层文件再导入；如果看到的是manifest.json和一堆 layer 目录，说明就是标准的 docker save 格式，可以跳过解压，直接用 docker load。

常见的翻车点是直接把外层 gz 包丢给 docker load。docker load 只认未压缩的 tar 或者标准的 oci 格式，.tar.gz会报unexpected EOF或者invalid tar header。所以预检这步不能省，我一般在离线环境部署前先跑一遍file命令确认格式：

file coredns_v1.8.0.tar.gz # 输出类似: gzip compressed data, was "coredns_v1.8.0.tar"

看到这行输出，先tar -xzf coredns_v1.8.0.tar.gz解压出内层 tar，再去 load。这一步用掉 10 秒，但能省掉后面一小时的排障时间。

3.2 导入镜像：Docker 与 containerd 的两条路径

不同节点的容器运行时不一样，导入方式也不同。节点用的是 Docker，直接 load：

docker load -i coredns_v1.8.0.tar

参数说明：-i指定输入的 tar 文件。导入完成后用docker images | grep coredns确认镜像仓库和 tag。如果发现 tag 和 K8s 期望的不一致，比如期望registry.k8s.io/coredns/coredns:v1.8.0，但包里是coredns/coredns:v1.8.0，可以用docker tag重新打标。打标后镜像 ID 不变，但 K8s 能按完整路径找到它。

如果是 containerd，docker load 就不好使了。这种情况多半是节点用的 runtime 是 containerd，或者干脆集群从 1.24 起默认就不装 docker。containerd 的导入工具是ctr或crictl，推荐用 ctr：

ctr -n=k8s.io images import coredns_v1.8.0.tar

参数说明：-n=k8s.io指定命名空间，K8s 通过 CRI 创建的镜像都放在k8s.io这个命名空间里；如果用默认命名空间导入，Kubelet 照样拉不到。这一步是很多人踩过的坑，镜像明明导进去了，Pod 还是ErrImagePull，查日志才发现 ctr 用的是 default namespace。

如果节点同时装了 crictl，也可以这样导入：

crictl images import coredns_v1.8.0.tar

但 crictl 需要连接 containerd 的 socket，可能遇到权限或 endpoint 配置问题。我习惯先走 ctr，因为不依赖额外配置，导入完直接ctr -n=k8s.io images list | grep coredns验证即可。

注意：导入后不要立刻重启 Kubelet，先确认镜像在正确 namespace。有的环境 Kubelet 有镜像拉取策略Always，即使本地有镜像也会尝试去远端拉取。离线环境需要在 Deployment 的 container 配置里把imagePullPolicy改成IfNotPresent或Never，否则离线包导了也白导。

3.3 Corefile 落地：把配置改成你想要的解析策略

镜像导入只解决「能拉起来」，真正决定解析行为的是 CoreDNS 的 ConfigMap。默认的 Corefile 长这样：

apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }

这段配置的含义要拆开讲。:53表示监听所有网卡的 53 端口；errors把解析错误写进标准输出；health开启健康检查端口 8080，lameduck 5s是优雅退出前的缓冲时间；ready暴露就绪状态；kubernetes插件是核心，cluster.local是集群域，in-addr.arpa和ip6.arpa是反向解析域，pods insecure表示 Pod 的 A 记录用 IP 代替点号拼接；forward . /etc/resolv.conf把所有非集群域的查询转发给节点上配置的 DNS，这个字段最容易出问题；cache 30表示缓存 30 秒；loop检测解析环路；loadbalance做随机负载均衡。

离线环境里最常改的是 forward 和 cache。内网没外网 DNS 的话，把/etc/resolv.conf换成你实际可用的上游：

kubectl edit configmap coredns -n kube-system

把forward . /etc/resolv.conf改成显式地址：

forward . 10.0.0.2 10.0.0.3 { max_concurrent 1000 }

参数说明：10.0.0.2和10.0.0.3是你内网 DNS 的 IP，改成实际环境即可；max_concurrent 1000限制同时处理的转发请求数量，防止上游抖动时突发流量把 CoreDNS 打爆。这个字段在 v1.8.0 里已经支持，但旧版本可能没有，配置后要确认 CoreDNS 日志不报unknown field。

改完 ConfigMap，CoreDNS 的 reload 插件会自动感知并加载新配置，不需要重启。如果没生效，用下面的命令强制滚动重启：

kubectl rollout restart deployment/coredns -n kube-system

4. 避坑记录：现场最容易翻车的五个细节

4.1 现象：docker load 导入 containerd 节点后 Pod 照样 ImagePullBackOff

某次给一个用 containerd 的集群部署 CoreDNS，我习惯性先docker load，显示导入成功，但 Pod 状态一直是ImagePullBackOff。看错误信息发现 Kubelet 去registry.k8s.io拉镜像，而不是用本地已有的镜像。

原因：containerd 节点的镜像库不是 docker 的，docker load 的数据落在 docker 的存储目录里，Kubelet 根本看不到。另外镜像 tag 的 registry 路径不是 K8s 期望的那个，Kubelet 不认识。

解决：先ctr -n=k8s.io images import重新导入，再用ctr -n=k8s.io images tag把 tag 改成registry.k8s.io/coredns/coredns:v1.8.0，最后检查 Deployment 的imagePullPolicy，改成IfNotPresent。

4.2 现象：CoreDNS 启动正常，但集群内域名解析超时

导入镜像、配置都改完后，CoreDNS Pod 是 Running，但业务 Pod 里ping svc-name卡住几秒后超时。看/etc/resolv.conf没问题，nameserver 指向 ClusterIP。

原因：我改 Corefile 时把forward指到了一个不存在的上游 IP。forward插件是同步查询，上游无响应时每个查询都会等到超时才返回，默认超时是 2 秒，加上重试就是 4 秒以上，业务层自然觉得 DNS 卡死了。

解决：先确认上游 DNS 可达，telnet 10.0.0.2 53测一下；再把 Corefile 里的 forward 改成真实可用的 DNS，或者继续用/etc/resolv.conf让 CoreDNS 读取节点配置。另外可以给 forward 加上expire 10s和max_fails 3，降低上游故障对集群的影响。

4.3 现象：域名解析结果是错的，Pod 跨命名空间访问失败

A 命名空间的 Pod 访问 B 命名空间的 Service，返回的 IP 始终不对，有时候解析到旧 Pod IP。

原因：DNS 缓存没刷新。CoreDNS 的cache 30是 TTL 30 秒，Service 关联的 Endpoint 变更后，如果缓存还没过期，解析结果仍然是旧的 ClusterIP。还有一种可能是我在kubernetes插件里设置成pods verified，Pod 启停频繁时记录更新跟不上。

解决：临时清缓存可以调低cache的 TTL，或者直接设置cache 5。生产环境我习惯保留pods insecure，让 Pod DNS 记录直接落到 Pod IP 而不是走 Endpoint 校验。如果问题持续，用kubectl logs -n kube-system deployment/coredns看查询日志，确认命中的是哪个后端。

4.4 现象：CoreDNS 内存飙高，Pod OOMKilled

某个集群 CoreDNS 刚部署两天，报 OOMKilled 重启，查看监控发现 RSS 涨到 1GB 以上。平时流量不大，不应该这么夸张。

原因：缓存过度增长。默认cache 30会缓存所有查询结果，如果线下环境有人频繁查询随机子域名，比如监控脚本对prometheus.monitor.svc.cluster.local做遍历，缓存表会被撑爆。

解决：加上cache插件的success和denial限制，只缓存成功响应，拒绝缓存 denial 响应。配置这样写：

cache 30 { success 2000 30 60 denial 0 5 5 }

参数说明：success 2000 30 60表示最多缓存 2000 条成功记录，缓存 30 秒，清理周期 60 秒；denial 0 5 5表示 NXDOMAIN 类响应不缓存。这样内存占用可控，也不会因为大量无效查询拖垮进程。

4.5 现象：修改 Corefile 后配置不生效，日志看到 reload 成功但行为没变

改完 ConfigMap 后，CoreDNS 日志打出reload成功的记录，但解析行为还是老样子，比如 forward 明明改了上游，查询还是走旧地址。

原因：Corefile 语法错了，reload 插件加载新配置失败回滚到旧配置，但日志里不会有明显报错；或者 ConfigMap 挂载到 Pod 的文件有延迟。

解决：先用kubectl get configmap coredns -n kube-system -o yaml确认对吧，再用下面命令进容器手测解析：

kubectl exec -it deployment/coredns -n kube-system -- /bin/sh # 进入容器后执行 nslookup kubernetes.default.svc.cluster.local 127.0.0.1

我一般还会加一句kubectl rollout restart deployment/coredns -n kube-system强制重建 Pod，排除文件挂载缓存问题。

5. 验证链路与调优：从 dig 到压测的一整套闭环

镜像导完、配置改完，不能只看 Pod Running 就收工。CoreDNS 是集群的命脉，验证要覆盖「查询链路」「上游转发」「缓存命中」三个层面。

先看链路通不通：

kubectl run digtest --image=registry.local/dig:latest --restart=Never --rm -it -- dig @$(kubectl get svc -n kube-system coredns -o jsonpath='{.spec.clusterIP}') kubernetes.default.svc.cluster.local

没有 dig 镜像也可以用 nslookup：

kubectl exec -it deployment/coredns -n kube-system -- nslookup kubernetes.default.svc.cluster.local 127.0.0.1

参数说明：@127.0.0.1表示在 CoreDNS 容器内查自身，返回的 A 记录应该是 Service 的 ClusterIP。如果返回的是<nil>或超时，优先检查 Corefile 里kubernetes插件的cluster.local域是否和集群实际配置一致。

再看上游转发。找一台业务 Pod，手动指定 CoreDNS 的 ClusterIP 解析外网域名：

kubectl exec -it your-pod -- nslookup example.com <core-dns-cluster-ip>

如果外网域名超时，问题基本在 forward 插件的上游配置。常见做法是先把上游改成节点/etc/resolv.conf里的 DNS，再逐个排除。

缓存命中率能通过 Prometheus 指标看到。CoreDNS 默认在:9153暴露 metrics，字段包括coredns_cache_hits_total和coredns_cache_misses_total。没有 Prometheus 的话，用一条命令临时抓取：

kubectl exec -it deployment/coredns -n kube-system -- wget -qO- http://127.0.0.1:9153/metrics | grep coredns_cache

关注两个数值：hits高说明缓存有效，misses高说明查询穿透到上游，需要调大cacheTTL 或检查是否有大量随机域名查询。还有一个值得关注的是coredns_dns_request_duration_seconds，P99 超过 100ms 就要检查上游 DNS 延迟，有条件的话在 forward 里加prefer_udp，减少 TCP 协商开销。

调优的优先级我一般这么排：先保证集群内解析时延小于 10ms，再优化上游转发的超时参数，最后才动缓存策略。loop插件务必保留，它能检测解析环路，防止 CoreDNS 转发到自身导致死循环。errors和log插件建议二选一，全量 log 在高流量下会刷爆磁盘。

那一次我在一个在线业务集群里调缓存参数，把cache 30改成了cache 300，查询命中率上去了，但某个服务扩容时新 Pod 依赖旧 IP 访问了好几轮，血泪教训。从那以后我每次调完缓存，都用dig连续查询两次看 TTL 递减，再从业务 Pod 里实际跑一轮 HTTP 请求验证，全部通过才交付，希望帮到你。

本文还有配套的精品资源，点击获取