CoreDNS v1.8.0二进制安装与K8s解析配置避坑

简介coredns_v1.8.0.tar.gz 是面向 Kubernetes 运维与容器平台学习者的 CoreDNS v1.8.0 镜像归档适用于 k8s v1.21.2 环境主要用于离线分发、镜像导入及版本核对等场景可缓解内网或受限网络下组件拉取不便的问题。压缩包共 8 个文件约 40.62MB包含 4 个 JSON 元数据、2 个 tar 层文件与 2 个 VERSION 版本标识分别对应镜像清单、层数据及版本信息结构较完整便于按 manifest 关系核验镜像内容。当前已有 408 人学习或下载说明其在同类离线镜像资料中具备一定参考价值。读者可据此获得与 k8s v1.21.2 配套的 CoreDNS 镜像文件用于集群 DNS 组件的离线部署准备、镜像一致性检查和环境复现适合需要减少外网依赖、快速搭建测试集群的运维人员与学习者。1. 别急着解压CoreDNS v1.8.0 在 k8s 里装错版本的代价k8s 里最容易背锅的组件之一就是 CoreDNS。项目标题给的是 coredns_v1.8.0.tar.gz很多人拿到包就直接解压、改 Corefile、重启结果集群里短域名时好时坏排查半天才发现是版本和插件参数不匹配。CoreDNS v1.8.0 不算新装它的人多半是在旧集群、离线环境或做迁移对照不是追新。装错版本或端口没让开表现不是服务起不来而是解析延迟、偶发超时像玄学。第 1 章先不贴命令先把装前要核对的版本、端口、运行用户说清新手照着后面步骤能走通熟手重点看第 4 章参数和第 5 章避坑。装完能验证解析链路这套环境才算落地。2. 装前核对CoreDNS v1.8.0 对 k8s 版本、端口和运行用户的要求项目标题只给了 coredns_v1.8.0.tar.gz没有给目标 k8s 版本也没有给包内结构。这种时候我不会先解压到生产目录更不会直接覆盖集群里正在跑的 DNS 服务。装前核对的目标只有一个确认这个包拿到当前环境里是“替换件”还是“旁路验证件”。如果集群里现有 DNS 服务版本更高Corefile 里可能已经有 v1.8.0 不认识的插件参数如果集群是旧环境CoreDNS v1.8.0 反而可能更接近现有配置。版本选择不是看谁新而是看 Corefile 能不能对上、插件有没有编译进去。2.1 版本选择与 k8s 兼容性核对我一般先备份当前集群的 DNS 配置再决定动不动手。命令不复杂关键是别在没备份的情况下改 Corefile。# 先看 k8s 系统命名空间里 DNS 相关配置名字不一定刚好叫 coredns kubectl -n kube-system get configmap | grep -i dns kubectl -n kube-system get configmap coredns -o yaml /tmp/coredns-current.yaml # 看当前 DNS Service 的 ClusterIP后面旁路验证要用 kubectl -n kube-system get svc kube-dns -o wide-n kube-system指定系统命名空间-o yaml把当前 Corefile 完整导出来改坏了至少有后悔药。get svc kube-dns是很多集群里 DNS Service 的固定名字但不同集群可能不同所以先用get svc看一眼不要上来就假定名字。备份文件放到/tmp只是临时做法正式变更前我会再复制一份到受控目录并记录变更时间。版本核对看三处现有 DNS 服务的镜像版本、Corefile 里的插件块、集群域名和上游 DNS。项目标题没有写 v1.8.0 支持哪些 k8s 版本我不会凭印象补一个版本矩阵。常见做法是拿现有 Corefile 做基线把 v1.8.0 先当旁路实例跑起来能解析集群域名和外部域名再考虑替换。如果现有 Corefile 里有 v1.8.0 没编译的插件块启动时会直接报 unknown directive这种错误不要靠改参数绕先确认插件是否存在。还有一点容易被忽略CoreDNS 的插件是在编译时决定的不是 Corefile 里写了就一定有。拿到 tar.gz 后要先确认它是二进制包还是源码包。二进制包直接看可执行文件源码包要按包内go.mod声明的 Go 版本准备工具链。生产机上临时补 Go 工具链风险高我一般会在构建环境里编好再拿过去不在 DNS 机器上边装边试。2.2 解压包内容与运行前置条件先列目录不急着解压到正式路径。项目正文没有给包内清单所以更不能预设里面一定是二进制。# -t 只列内容-z 处理 gzip-f 指定文件先看前 40 行避免刷屏 tar -tzf coredns_v1.8.0.tar.gz | sed -n 1,40p # 确认顶层目录结构后再解压到临时目录检查 mkdir -p /tmp/coredns-inspect tar -xzf coredns_v1.8.0.tar.gz -C /tmp/coredns-inspect # 找可执行文件、Corefile 示例或源码标记 find /tmp/coredns-inspect -maxdepth 3 -type f \ \( -name coredns -o -name go.mod -o -name Corefile \) -print # 如果是可执行文件看文件类型别把脚本或源码目录当二进制 file /tmp/coredns-inspect/*/coredns 2/dev/null || truetar -tzf只读不写适合第一次检查。sed -n 1,40p限制输出行数包再大也不会把终端刷满。find里用-maxdepth 3控制深度避免在源码目录里翻太久。file的结果如果是 ELF 可执行文件才走二进制安装如果只有go.mod说明是源码包编译步骤要单独安排不要和 DNS 服务切换混在一起。运行前置条件里最关键的是运行用户和 53 端口权限。DNS 默认监听 53非 root 用户不能直接绑定低端口。我的习惯是建专用用户给二进制文件cap_net_bind_service能力而不是整台机器都用 root 跑 DNS。# 专用系统用户不建家目录不允许登录 useradd --system --no-create-home --shell /usr/sbin/nologin coredns # 目录属主 root、属组 coredns权限 0750配置文件不让普通用户随便改 install -d -m 0750 -o root -g coredns /opt/coredns-v1.8.0 /etc/coredns # 给二进制绑定低端口的能力路径按实际解压位置改 setcap cap_net_bind_serviceep /opt/coredns-v1.8.0/corednsuseradd --system建的是系统用户--no-create-home避免多出无用目录。install -d同时建目录并设权限比mkdir再chmod少一步。setcap只给绑定低端口的能力不是给 root 权限。注意如果后面用服务管理器再给AmbientCapabilities这一步可以二选一两个都做不算错但要知道自己在用哪条路径排错时别把权限问题绕晕。2.3 端口、资源和运行用户预检CoreDNS 默认会用到 53、9153、8080、8181 这几个端口。53 是 DNS9153 是指标8080 是健康检查8181 是就绪检查。端口都能改但改之前先看占用别等服务起来才发现冲突。# 看 53、1053、9153、8080、8181 是否已被占用 ss -lntup | grep -E :(53|1053|9153|8080|8181)\b || true # 看当前文件描述符上限DNS 并发高时这个值太小会先出问题 ulimit -nss -lntup里-l看监听-n不做域名解析-t看 TCP-u看 UDP-p带进程。DNS 同时用 UDP 和 TCP所以两个协议都要看。|| true只是让没匹配到时命令不以非零状态打断脚本不是掩盖错误。端口协议用途预检要点53UDP/TCPDNS 服务是否被本机 DNS 服务占用防火墙是否放行两个协议9153TCP指标暴露是否只在内网开放别直接暴露到公网8080TCP健康检查探针路径和端口是否与 Corefile 一致8181TCP就绪检查k8s 里就绪探针常看这个端口资源上我不会拍一个固定内存值。CoreDNS 本身不重但缓存条目、集群规模、查询频率都会影响内存。常见做法是拿当前 DNS 服务副本的 requests/limits 做基线先保持同等规格旁路验证时看指标再调。运行用户方面如果后面要进 k8s容器安全上下文要允许绑定 53要么给NET_BIND_SERVICE要么以 root 启动后降权二选一不要既改 capability 又改用户最后不知道是哪条生效。3. 从 tar.gz 落地CoreDNS v1.8.0 二进制安装与服务化装前核对完才开始落地。这个包如果是二进制发布包安装动作其实很轻解压、放目录、写 Corefile、前台跑通、再服务化。真正容易翻车的是直接上 53 端口、直接改集群 DNS出错后没有回退路径。我的顺序是先用 1053 旁路端口跑确认插件加载、转发、缓存都正常再切 53 或接进 k8s。3.1 解压与目录规划目录规划我习惯把二进制和配置分开/opt/coredns-v1.8.0放可执行文件/etc/coredns放 Corefile。这样升级时只换二进制目录配置不动回滚时也只换目录不把配置搅在一起。# 解压到版本目录--strip-components1 去掉压缩包顶层目录 # 只有在 tar -tzf 确认包内有一个顶层目录时才加这个参数 tar -xzf coredns_v1.8.0.tar.gz -C /opt/coredns-v1.8.0 --strip-components1 # 确认二进制可执行 ls -l /opt/coredns-v1.8.0/coredns chmod 0755 /opt/coredns-v1.8.0/coredns # 配置目录单独放权限收紧 install -d -m 0750 -o root -g coredns /etc/coredns--strip-components1不是必选项。如果包内没有统一顶层目录加了这个参数会把文件铺到目标目录根下反而乱。所以先tar -tzf看结构再决定加不加。chmod 0755让二进制可执行但目录和配置不要给普通用户写权限。install -d建配置目录时就把属组设为coredns后面服务以该用户运行才能读配置。如果解压后没有coredns可执行文件只有源码目录不要在这台机器上直接go build了事。先确认包内go.mod的 Go 版本要求在构建环境里编好再把二进制放进来。DNS 机器上少装一套工具链后面排错少一个变量。3.2 前台启动与 Corefile 最小验证第一次启动不要直接上 53。用-dns.port 1053起一个旁路实例和本机 DNS 服务错开。Corefile 也先写最小配置只验证插件加载和转发不急着把 kubernetes 插件全量搬进来。# 写一个最小 Corefile上游 DNS 用文档保留地址占位实际换成你的上游 cat /etc/coredns/Corefile EOF .:1053 { errors health :8080 ready :8181 forward . 192.0.2.53 198.51.100.53 cache 30 log } EOF # 前台启动先看日志里插件是否加载成功CtrlC 退出 cd /opt/coredns-v1.8.0 ./coredns -conf /etc/coredns/Corefile -dns.port 1053.:1053表示监听 1053 端口-dns.port 1053再显式指定一次避免 Corefile 里端口和启动参数不一致。errors把错误打到日志health和ready分别开健康、就绪端口forward指向上游 DNScache 30缓存 30 秒log在调试期打开。这里的192.0.2.53和198.51.100.53是文档保留地址只做占位不要照抄到生产实际要换成你环境里可用的上游 DNS。前台跑起来后另开一个终端验证# 查根域名 NS验证 DNS 进程能响应 dig 127.0.0.1 -p 1053 . NS time2 tries1 # 查健康端口返回 200 才算健康检查通 curl -sS -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/healthtime2 tries1让 dig 快速失败不要在调试时等默认超时。健康检查返回 200 只说明进程活着不代表解析链路全通根域名 NS 查询能返回结果才说明监听、转发至少有一条通。如果这一步就失败先别继续写 kubernetes 插件回到端口和上游 DNS 查。3.3 服务化与开机拉起前台验证通过后再服务化。下面给一个常见的服务单元模板字段按你的系统调整。关键点是运行用户、配置文件路径、低端口能力和重启策略。[Unit] DescriptionCoreDNS v1.8.0 DNS service Afternetwork-online.target Wantsnetwork-online.target [Service] Usercoredns Groupcoredns ExecStart/opt/coredns-v1.8.0/coredns -conf /etc/coredns/Corefile Restarton-failure RestartSec5 LimitNOFILE1048576 AmbientCapabilitiesCAP_NET_BIND_SERVICE CapabilityBoundingSetCAP_NET_BIND_SERVICE NoNewPrivilegestrue [Install] WantedBymulti-user.targetUser和Group让服务以专用用户运行ExecStart里不要写相对路径。Restarton-failure让异常退出后自动拉起RestartSec5避免频繁重启刷日志。LimitNOFILE提高文件描述符上限DNS 并发高时有用。AmbientCapabilities给非 root 用户绑定 53 的能力NoNewPrivilegestrue防止再提权。如果前面已经用setcap给二进制加了能力这里可以保留服务单元的能力配置但排错时要清楚是哪一层生效。# 重新加载服务管理器配置并设置开机自启 systemctl daemon-reload systemctl enable --now coredns # 看状态和最近日志启动失败先看这里 systemctl status coredns --no-pager journalctl -u coredns -n 80 --no-pagerdaemon-reload在改完单元文件后必须执行否则服务管理器还在用旧配置。enable --now同时设置开机自启和立即启动。status看退出码journalctl -n 80看最近日志。如果日志里出现bind: permission denied先回到能力配置出现address already in use先回到端口占用不要混在一起改。3.4 接入 k8s 前的旁路验证CoreDNS v1.8.0 接进 k8s 之前我仍然建议在本机 1053 端口跑一个带kubernetes插件的实例。这样即使 Corefile 写错也只影响旁路端口不会把集群 DNS 打挂。先看当前集群的 Corefile 和 Service# 导出当前 Corefile重点看 kubernetes 插件块和 cluster 域名 kubectl -n kube-system get configmap coredns -o jsonpath{.data.Corefile} # 看 DNS Service 的 ClusterIP旁路验证时可以用它做对照 kubectl -n kube-system get svc kube-dns -o jsonpath{.spec.clusterIP}{\n}jsonpath只取需要字段输出比整份 YAML 干净。当前 Corefile 里的kubernetes块是重要基线尤其是 zone、pods和fallthrough参数。不要把别的集群的 Corefile 直接复制过来服务网段、集群域名、API 地址都可能不同。旁路实例需要访问 k8s API 的 token 和 CA。不同 k8s 版本取 token 的方式不一样旧环境可能在 Secret 里新环境用 TokenRequest。我不会在文章里写死某一条命令让你照抄因为取错 token 的表现是kubernetes插件一直不就绪很容易误判成 CoreDNS 坏了。常见做法是直接复用当前 DNS 服务使用的 ServiceAccount 和挂载路径先在旁路进程里指向同一套凭证确认能解析kubernetes.default.svc这类集群内名称再替换。4. 配置 Corefilek8s 域名解析、缓存和转发的参数取舍Corefile 是 CoreDNS 的黑匣子入口但它的参数不是越多越好。装 CoreDNS v1.8.0 时我先把配置分成三层基础层放errors、health、ready解析层放kubernetes和forward缓存层放cache。每层只解决一个问题出问题时能快速定位是哪一层。4.1 最小可用 Corefile 逐行拆解下面是一份带 k8s 插件的最小配置。它不一定适合所有集群但结构清楚适合旁路验证时改。cat /etc/coredns/Corefile EOF .:53 { errors health :8080 { lameduck 5s } ready :8181 kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . 192.0.2.53 198.51.100.53 cache 30 loop reload loadbalance } EOF.:53表示默认域名、53 端口。errors放最前插件报错能进日志。health开 8080lameduck 5s让进程退出前延迟 5 秒减少切换时丢查询。ready开 8181k8s 就绪探针可以看这个端口。kubernetes cluster.local ...里的cluster.local要换成集群实际域名不确定就看当前 Corefile。pods insecure返回 Pod 记录fallthrough让反向解析未命中时继续走后面的forward。ttl 30控制 kubernetes 插件返回记录的 TTL。prometheus :9153暴露指标。forward指上游 DNS。cache 30缓存响应。loop检测转发循环reload支持配置热加载loadbalance打乱多条 A/AAAA 记录顺序。注意cache 30和ttl 30不是一回事。ttl 30是 kubernetes 插件返回记录时带的 TTL影响客户端缓存多久cache 30是 CoreDNS 自己缓存响应多久。两个都写 30 只是调试期方便记生产上要按业务域名变更频率调。域名切换频繁的集群缓存太长会让旧记录多活一段时间查询量大的集群缓存太短会把压力推给 API 和上游。4.2 kubernetes 插件参数zone、pods、fallthroughkubernetes插件是 k8s 解析的核心。zone 写错集群内域名会全部落到forward表现是短域名解析失败、外部域名正常。pods参数决定 Pod 记录怎么返回insecure不做 API 校验速度快但安全性弱verified会做校验对权限和 API 压力更敏感。常见做法是先用insecure把解析跑通安全要求高的环境再评估verified不要一上来就开最严模式否则权限没配好会一直不就绪。fallthrough in-addr.arpa ip6.arpa是反向解析的兜底。没有它查反解未命中时可能直接返回 NXDOMAIN不会继续问上游。反向解析在日志排查、监控定位里有用但也不是所有环境都必须开。我的习惯是保留这行旁路验证时用dig -x查一个集群内 IP确认反向记录能返回查不到时再看上游是不是支持反解。参数表如下改之前先对照当前 Corefile参数常用值作用取舍kuberneteszonecluster.local指定集群域名后缀必须与集群实际域名一致podsinsecure/verified控制 Pod 记录返回方式先跑通再收紧别一上来卡权限fallthroughin-addr.arpa ip6.arpa反向解析未命中时继续转发需要反解就留不需要可去掉ttl30集群记录 TTL域名变更频繁就调小endpoint不写时用 Service指定 API 地址旁路验证时按实际 API 地址改endpoint这行不是必写项。在 k8s 里跑时通常通过 Service 和环境变量访问 API本机旁路才需要显式指定。写错 endpoint 的表现是kubernetes插件启动慢、日志里反复连接失败但 DNS 进程本身还在容易误判成“服务正常但解析不对”。4.3 cache、forward 与 health/ready 的配合forward是外部解析的出口。很多人直接写forward . /etc/resolv.conf在宿主机上可能没问题在容器里就可能把查询转发给自己形成循环。我的习惯是显式写上游 DNS尤其在容器环境里如果一定要用/etc/resolv.conf先确认里面的地址不是本 Pod 的 DNS 地址。旁路验证时用文档保留地址占位切生产前换成真实上游。cache放的位置要配合forward。缓存放在转发后面能减少重复查询缓存时间太长域名切换后客户端拿不到新记录。调试期我会把cache设短比如 30 秒确认解析链路稳定后再调大。health和ready不是一回事health只表示进程活着ready表示插件已经就绪。本文还有配套的精品资源点击获取