1. 为什么值得花时间把 coreDNS 吃透如果你正在接触容器编排、集群内服务发现或者被 DNS 解析超时、随机解析失败、跨命名空间访问不通这类问题反复折磨那 coreDNS 这个名字你一定绕不开。它是 Kubernetes 生态里默认的集群 DNS 组件负责把服务名翻译成可访问的地址是整个集群服务发现链路里最不起眼、却最容易在关键时刻掉链子的一环。我见过太多团队业务代码写得漂漂亮亮结果一个 DNS 5 秒超时把整条调用链拖垮排查半天最后发现是 coreDNS 副本不够或者缓存配置不合理。这篇内容面向三类人一是刚接手集群、需要搞明白 coreDNS 到底怎么运转的运维和开发二是正在做服务发现方案选型、想搞清楚 coreDNS 与其它 DNS 方案差异的架构同学三是已经被 DNS 问题坑过、想系统补齐这块知识盲区的一线工程师。我会从整体设计思路讲起把核心配置、插件机制、实操部署、问题排查一条线串下来中间穿插我自己踩过的坑和实测有效的调优手段。读完你至少能做到看懂一份 Corefile、独立部署一套 coreDNS、定位大部分集群内 DNS 解析异常。需要先说明一点coreDNS 本身是一个通用的 DNS 服务器它不绑定任何特定平台只是因为在容器编排场景里被广泛采用才和集群服务发现深度绑定。理解这一点很重要因为它的能力边界远比集群 DNS这个标签要宽——你完全可以用它做本地开发环境的域名解析、做内网 DNS 转发、做简单的分流和拦截。下面所有内容都围绕这个定位展开既讲它在集群里的典型用法也讲它作为一个独立 DNS 服务的通用能力。2. 整体设计与思路拆解2.1 coreDNS 到底是个什么东西一句话概括coreDNS 是一个用 Go 写的、插件化架构的 DNS 服务器。它把 DNS 处理流程拆成一条插件链每个请求从链头进入依次经过各个插件每个插件决定自己是处理、修改还是放行这个请求。这个设计是它和传统 DNS 服务比如 BIND最大的区别——BIND 是配置驱动的庞然大物coreDNS 是代码驱动、插件拼装的轻量服务。我用一个生活化的类比来解释插件链把一次 DNS 查询想象成一件快递包裹coreDNS 是一条分拣流水线每个插件就是一个工位。包裹进来后第一个工位可能看地址决定要不要拦下来自己处理比如hosts插件直接返回本地记录不处理就往后传下一个工位可能负责查缓存cache插件命中就直接返回再往后可能是真正去上游查询的工位forward插件。整条流水线怎么排、每个工位开不开全写在 Corefile 里。这种设计带来的直接好处是按需组合。你不需要为一个简单场景背上一整套 DNS 功能只要拼出你需要的那几个插件就行。代价是插件顺序有讲究顺序错了行为就错这一点后面会专门讲。2.2 为什么是插件链而不是大配置文件传统 DNS 服务的配置文件往往是一个文件描述所有行为功能全但耦合重改一处容易影响一片。coreDNS 选择插件链本质是把行为变成可组装的组件每个组件职责单一。这个取舍背后的逻辑很清晰可测试性每个插件可以独立测试行为边界清楚出问题容易定位到具体插件。可扩展性要加一个新能力写一个新插件挂进链里即可不用动核心逻辑。可读性Corefile 里一段forward . 8.8.8.8一眼就知道在干什么比翻几百行传统配置直观得多。但插件链也带来一个隐形成本顺序即语义。同样几个插件排列不同结果可能完全不一样。比如cache放在forward前面才能缓存上游结果放后面就形同虚设。这是新手最容易忽略的点我在第 3 节会给出一个推荐的通用顺序模板。2.3 它在集群服务发现里扮演的角色在容器编排环境里coreDNS 承担的是集群内 DNS职责。每个 Pod 启动时容器运行时会把它的 DNS 服务器指向 coreDNS 的集群地址于是 Pod 里所有对服务名的解析请求都会打到 coreDNS。coreDNS 收到请求后通过对接集群 API 拿到 Service 与 Endpoint 信息把服务名.命名空间.svc.集群域这样的名字翻译成对应的集群地址。这里有个关键点很多人没意识到coreDNS 本身不存储服务信息它只是把查询转发给集群 API 或者依赖一个专门的插件去读取。所以当服务解析异常时问题可能根本不在 coreDNS而在 API 访问、网络策略或者 Endpoint 没就绪。理解这个数据流向是排查问题的前提。我后面第 5 节的排查表就是按这个链路来组织的。2.4 方案选型的几个现实考量如果你在选一个 DNS 服务coreDNS 的适用场景大致是需要轻量、需要和容器生态无缝配合、需要灵活的分流和转发策略。它的优势在于部署简单一个二进制或一个容器镜像、配置直观、社区活跃。相对地如果你需要极致的权威 DNS 功能、复杂的区域传输、海量记录的托管传统专业 DNS 服务可能更合适。我个人的判断标准很朴素如果你的场景里服务发现和转发分流是主诉求coreDNS 基本是最省心的选择如果你要做一个对外提供权威解析的公共 DNS那要评估它的权威能力和运维成熟度是否匹配。这个判断没有绝对对错关键是别拿一个为服务发现优化的工具去硬扛它不擅长的活。3. 核心细节解析与实操要点3.1 Corefile 的结构与插件顺序Corefile 是 coreDNS 的灵魂它的基本结构是服务器块 插件指令。一个服务器块以地址开头大括号里写插件。最简单的例子.:53 { forward . 8.8.8.8 1.1.1.1 cache 30 log errors }这段的意思是监听 53 端口所有域名.的查询先走cache缓存 30 秒未命中则forward到两个上游同时打印日志和错误。注意这里我故意把cache写在forward前面——虽然 coreDNS 会按插件注册的固定顺序执行但你在 Corefile 里的书写顺序在多数情况下不影响执行顺序真正决定顺序的是插件在编译时注册的优先级。这一点常被误解我实测确认过Corefile 里插件书写顺序基本不影响执行顺序执行顺序由插件自身的注册顺序决定。所以你不用纠结cache 要不要写在 forward 前面但你要知道 cache 天然就在 forward 之前生效。一个推荐的通用顺序模板按实际生效顺序理解阶段典型插件作用前置拦截hosts、template本地记录、自定义应答缓存cache缓存上游结果降低延迟转发forward、proxy把请求交给上游观测log、errors、prometheus日志、错误、指标兜底whoami、health健康检查、调试注意health和ready这类插件是给探针用的别和业务解析逻辑混在一起理解它们只回答我活着吗。3.2 缓存插件的参数怎么定cache是性能调优的第一杠杆但参数拍脑袋定很容易出问题。它的核心参数是 TTL 上限写法如cache 30表示最长缓存 30 秒。这里有个容易踩的坑缓存 TTL 不能超过上游记录本身的 TTLcoreDNS 会取两者较小值。所以你把 cache 设成 300但上游记录 TTL 只有 5实际还是 5 秒过期。那 TTL 设多少合适我的经验是按服务变更频率来定。服务地址频繁变动的环境TTL 设短比如 5 到 30 秒保证变更尽快生效相对稳定的环境可以设长60 到 300 秒降低上游压力。但别设太长否则服务扩缩容后旧地址还在缓存里会出现服务明明起来了却访问不到的诡异现象。我一般从 30 秒起步观察一段时间再调。还有一个参数是prefetch它会在缓存条目快过期时提前刷新适合高频访问的域名能避免缓存刚过期瞬间的查询抖动。写法是cache 30 { prefetch 5 10m 10% }含义是当某域名 10 分钟内被请求超过 10 次、且剩余 TTL 低于 10% 时提前刷新。这个参数对稳定性要求高的场景很有用但会增加上游查询量按需开启。3.3 forward 与上游选择forward决定请求最终去哪。写法forward . 8.8.8.8表示所有域名转发到该地址。实际生产里更常见的是按域名分流.:53 { forward example.internal 10.0.0.10 forward . /etc/resolv.conf }第一行把内部域名转到内网 DNS第二行其余走系统解析配置。这种分流的价值在于内部域名不出网、外部域名正常解析既安全又高效。上游选择上有几个实操要点。一是多上游要写多个地址coreDNS 会在它们之间做负载和故障转移写法forward . 8.8.8.8 1.1.1.1。二是注意上游的响应策略默认是随机选一个如果某个上游不稳定可以配合policy参数调整。三是别把上游写成自己形成环路会导致解析彻底挂掉这个错误我在早期配置时犯过表现为所有解析超时排查了很久才发现是转发目标指回了本机。3.4 插件 hosts 与 template 的妙用hosts插件让你像改本机 hosts 文件一样给 coreDNS 加静态记录写法hosts { 10.0.0.5 api.internal fallthrough }fallthrough很关键它表示这条记录没匹配上就继续往后走不加的话没匹配的请求会被直接拒绝。这个细节坑过不少人——加了 hosts 却没加 fallthrough结果所有其它域名都解析失败。template插件更灵活可以按模式动态生成应答适合做简单的自定义解析逻辑。比如给一批内部域名统一返回某个地址。它的语法稍复杂但胜在不用改代码就能实现规则化应答。我一般只在确实需要按规则批量应答时才用它简单静态记录用 hosts 就够了别为了炫技把配置搞复杂。3.5 观测类插件别省log、errors、prometheus这三个插件我建议默认都开。log打印每次查询排查时是救命稻草errors单独收集错误避免错误被淹没prometheus暴露指标配合监控能看到 QPS、缓存命中率、上游延迟这些关键数据。有人担心log影响性能确实高频场景下日志量很大。折中做法是用log的过滤能力只记录特定域名或特定响应码比如只记错误。我的习惯是平时开 errors 和 prometheus排查期临时开 log问题定位完就关掉。这样既保证可观测性又不给生产添负担。4. 实操过程与核心环节实现4.1 从零部署一套 coreDNS先讲独立部署不依赖任何编排平台这样你能看清它最本质的形态。准备一台机器下载对应平台的 coreDNS 二进制写一个最小 Corefile.:53 { forward . 8.8.8.8 1.1.1.1 cache 30 log errors prometheus :9153 health :8080 }启动命令./coredns -conf Corefile。启动后验证用dig 127.0.0.1 example.com查询能拿到应答就说明通了。health插件暴露在 8080 端口curl http://127.0.0.1:8080/health返回 ok 表示服务健康。prometheus在 9153 端口暴露指标可以接监控。这里有个部署细节53 端口是特权端口非 root 运行需要额外授权。生产环境我倾向于用容器方式跑把端口映射处理好避免直接给二进制提权。容器化部署时把 Corefile 挂载进去镜像用官方精简镜像即可启动参数指向挂载路径。4.2 在集群环境里的部署要点集群里部署 coreDNS核心是让它能读到服务信息、能被 Pod 正确指向。典型做法是以 Deployment 形式跑多个副本配一个 Service 暴露 53 端口然后把集群的 DNS 配置指向这个 Service 地址。副本数别只开一个我建议至少两个并且配合反亲和性打散到不同节点——单副本一旦所在节点故障整个集群的解析都会受影响这个故障面太大了。资源配置上coreDNS 本身很轻但要注意内存限制别设太小。缓存会占内存限制过紧会导致频繁驱逐甚至 OOM。我一般给每个副本 128Mi 到 256Mi 的起步内存观察实际用量再调。CPU 方面请求量大的集群要给足否则高 QPS 下会出现排队延迟。还有一个容易被忽略的点coreDNS 的探针配置。liveness 探针打 health 端口readiness 探针打 ready 端口两者别配反。我见过把 readiness 配成 health 端口的结果服务还没准备好就被判定就绪流量打进来解析失败。正确做法是 liveness 用/healthreadiness 用/ready。4.3 一个带分流的完整 Corefile 示例下面这份配置是我在一个混合环境里实际用过的简化版兼顾内部解析、外部转发和可观测性.:53 { errors health :8080 ready :8181 prometheus :9153 hosts { 10.0.0.5 api.internal fallthrough } cache 30 { prefetch 5 10m 10% } forward internal.example 10.0.0.10 forward . 8.8.8.8 1.1.1.1 log . { class denial error } }逐段说明errors收集错误health和ready给探针用prometheus暴露指标hosts加一条静态记录并 fallthroughcache开 30 秒缓存并启用预取两条forward做内外分流log只记录被拒绝和错误的查询控制日志量。这份配置可以直接拿去改改就用域名和地址换成你自己的即可。4.4 验证与压测部署完别急着上线先做两件事。一是功能验证分别查内部域名、外部域名、不存在的域名确认返回符合预期。内部域名应该命中 hosts 或内网转发外部域名正常解析不存在的域名返回 NXDOMAIN 而不是超时。二是压测用 DNS 压测工具打一轮观察 QPS、延迟和缓存命中率。缓存命中率低说明 TTL 太短或查询太分散延迟高要看是不是上游慢。压测时重点看prometheus指标里的缓存命中率和上游请求延迟。我实测下来合理配置缓存后命中率通常能到七八成以上上游压力明显下降。如果命中率很低先检查是不是每个查询的域名都不同比如带随机子域那种场景缓存天然无效得从业务侧优化。5. 常见问题与排查技巧实录5.1 解析超时与随机失败这是最高频的问题表现是 Pod 里访问服务时好时坏日志里出现解析超时。排查思路按链路走先确认 coreDNS 副本是否健康、是否够用再看是不是缓存 TTL 太长导致旧地址然后查上游是否可达最后看网络策略有没有拦截 DNS 流量。一个经典原因是并发查询被上游限流。coreDNS 默认对同一上游的并发查询有限制高 QPS 下超出部分会排队甚至超时。解决办法是增加上游数量、调大并发参数或者优化缓存降低上游压力。我遇到过一次业务侧短时间大量新域名查询把上游打满加了缓存和预取后明显缓解。5.2 服务名解析不到服务明明存在却解析不到先分清是名字格式不对还是数据没同步。名字格式上完整格式是服务名.命名空间.svc.集群域少一段可能就解析不到。数据同步上coreDNS 依赖集群 API 拿服务信息如果 API 访问异常或者 Endpoint 没就绪解析就会失败。排查时我会先在 coreDNS 所在环境直接查一次完整域名确认 coreDNS 本身能不能解析能解析说明问题在调用方比如命名空间不对不能解析再往 API 和 Endpoint 方向查。这个先隔离 coreDNS 自身的思路能省很多时间。5.3 缓存导致的服务已更新但访问旧地址服务扩缩容或重建后地址变了但调用方还在访问旧地址十有八九是缓存 TTL 太长。短期办法是重启 coreDNS 清缓存粗暴但有效长期办法是把 TTL 调短或者对变更频繁的服务单独用更短的 TTL。这里没有银弹本质是缓存一致性和上游压力之间的权衡按业务对变更生效速度的要求来定。5.4 常见问题速查表现象可能原因排查动作处理建议解析随机超时副本不足、上游限流看副本数、上游延迟指标加副本、加缓存、扩上游服务名解析不到名字格式错、Endpoint 未就绪直接查完整域名隔离修正格式、检查服务状态访问旧地址缓存 TTL 过长查缓存配置调短 TTL 或清缓存所有解析失败转发环路、上游不可达检查 forward 目标修正上游、避免指回自身加了 hosts 后其它域名失效缺 fallthrough检查 hosts 配置补 fallthrough高 QPS 下延迟飙升CPU 不足、缓存命中低看 CPU 和命中率加资源、优化缓存5.5 几条踩坑心得第一别在 Corefile 里写自己解析不了的转发目标环路问题排查成本极高配置前先想清楚数据流向。第二hosts 插件一定记得 fallthrough这个坑几乎每个新手都会踩一次。第三探针端口别配反liveness 和 readiness 用错端口会导致流量在服务未就绪时涌入。第四缓存 TTL 是双刃剑调优前先想清楚业务对变更生效速度的容忍度。第五日志按需开生产常开全量日志既费磁盘又影响性能用过滤只记关键信息。我个人在实际操作中的体会是coreDNS 的配置本身不难难的是理解它在整条服务发现链路里的位置。很多所谓的coreDNS 问题根子其实在服务状态、网络策略或者调用方配置。把数据流向在脑子里画清楚——请求从 Pod 出发经过 coreDNS再到上游或集群 API——排查时顺着这条线一段段验证绝大多数问题都能快速定位。这套思路比记住任何单个参数都值钱。 
长河君 · 2026/10/26 19:52:33 · 阅读 1.2k CoreDNS 插件链设计与集群服务发现实战：从 Corefile 配置到 DNS 解析故障排查
1. 为什么值得花时间把 coreDNS 吃透如果你正在接触容器编排、集群内服务发现或者被 DNS 解析超时、随机解析失败、跨命名空间访问不通这类问题反复折磨那 coreDNS 这个名字你一定绕不开。它是 Kubernetes 生态里默认的集群 DNS 组件负责把服务名翻译成可访问的地址是整个集群服务发现链路里最不起眼、却最容易在关键时刻掉链子的一环。我见过太多团队业务代码写得漂漂亮亮结果一个 DNS 5 秒超时把整条调用链拖垮排查半天最后发现是 coreDNS 副本不够或者缓存配置不合理。这篇内容面向三类人一是刚接手集群、需要搞明白 coreDNS 到底怎么运转的运维和开发二是正在做服务发现方案选型、想搞清楚 coreDNS 与其它 DNS 方案差异的架构同学三是已经被 DNS 问题坑过、想系统补齐这块知识盲区的一线工程师。我会从整体设计思路讲起把核心配置、插件机制、实操部署、问题排查一条线串下来中间穿插我自己踩过的坑和实测有效的调优手段。读完你至少能做到看懂一份 Corefile、独立部署一套 coreDNS、定位大部分集群内 DNS 解析异常。需要先说明一点coreDNS 本身是一个通用的 DNS 服务器它不绑定任何特定平台只是因为在容器编排场景里被广泛采用才和集群服务发现深度绑定。理解这一点很重要因为它的能力边界远比集群 DNS这个标签要宽——你完全可以用它做本地开发环境的域名解析、做内网 DNS 转发、做简单的分流和拦截。下面所有内容都围绕这个定位展开既讲它在集群里的典型用法也讲它作为一个独立 DNS 服务的通用能力。2. 整体设计与思路拆解2.1 coreDNS 到底是个什么东西一句话概括coreDNS 是一个用 Go 写的、插件化架构的 DNS 服务器。它把 DNS 处理流程拆成一条插件链每个请求从链头进入依次经过各个插件每个插件决定自己是处理、修改还是放行这个请求。这个设计是它和传统 DNS 服务比如 BIND最大的区别——BIND 是配置驱动的庞然大物coreDNS 是代码驱动、插件拼装的轻量服务。我用一个生活化的类比来解释插件链把一次 DNS 查询想象成一件快递包裹coreDNS 是一条分拣流水线每个插件就是一个工位。包裹进来后第一个工位可能看地址决定要不要拦下来自己处理比如hosts插件直接返回本地记录不处理就往后传下一个工位可能负责查缓存cache插件命中就直接返回再往后可能是真正去上游查询的工位forward插件。整条流水线怎么排、每个工位开不开全写在 Corefile 里。这种设计带来的直接好处是按需组合。你不需要为一个简单场景背上一整套 DNS 功能只要拼出你需要的那几个插件就行。代价是插件顺序有讲究顺序错了行为就错这一点后面会专门讲。2.2 为什么是插件链而不是大配置文件传统 DNS 服务的配置文件往往是一个文件描述所有行为功能全但耦合重改一处容易影响一片。coreDNS 选择插件链本质是把行为变成可组装的组件每个组件职责单一。这个取舍背后的逻辑很清晰可测试性每个插件可以独立测试行为边界清楚出问题容易定位到具体插件。可扩展性要加一个新能力写一个新插件挂进链里即可不用动核心逻辑。可读性Corefile 里一段forward . 8.8.8.8一眼就知道在干什么比翻几百行传统配置直观得多。但插件链也带来一个隐形成本顺序即语义。同样几个插件排列不同结果可能完全不一样。比如cache放在forward前面才能缓存上游结果放后面就形同虚设。这是新手最容易忽略的点我在第 3 节会给出一个推荐的通用顺序模板。2.3 它在集群服务发现里扮演的角色在容器编排环境里coreDNS 承担的是集群内 DNS职责。每个 Pod 启动时容器运行时会把它的 DNS 服务器指向 coreDNS 的集群地址于是 Pod 里所有对服务名的解析请求都会打到 coreDNS。coreDNS 收到请求后通过对接集群 API 拿到 Service 与 Endpoint 信息把服务名.命名空间.svc.集群域这样的名字翻译成对应的集群地址。这里有个关键点很多人没意识到coreDNS 本身不存储服务信息它只是把查询转发给集群 API 或者依赖一个专门的插件去读取。所以当服务解析异常时问题可能根本不在 coreDNS而在 API 访问、网络策略或者 Endpoint 没就绪。理解这个数据流向是排查问题的前提。我后面第 5 节的排查表就是按这个链路来组织的。2.4 方案选型的几个现实考量如果你在选一个 DNS 服务coreDNS 的适用场景大致是需要轻量、需要和容器生态无缝配合、需要灵活的分流和转发策略。它的优势在于部署简单一个二进制或一个容器镜像、配置直观、社区活跃。相对地如果你需要极致的权威 DNS 功能、复杂的区域传输、海量记录的托管传统专业 DNS 服务可能更合适。我个人的判断标准很朴素如果你的场景里服务发现和转发分流是主诉求coreDNS 基本是最省心的选择如果你要做一个对外提供权威解析的公共 DNS那要评估它的权威能力和运维成熟度是否匹配。这个判断没有绝对对错关键是别拿一个为服务发现优化的工具去硬扛它不擅长的活。3. 核心细节解析与实操要点3.1 Corefile 的结构与插件顺序Corefile 是 coreDNS 的灵魂它的基本结构是服务器块 插件指令。一个服务器块以地址开头大括号里写插件。最简单的例子.:53 { forward . 8.8.8.8 1.1.1.1 cache 30 log errors }这段的意思是监听 53 端口所有域名.的查询先走cache缓存 30 秒未命中则forward到两个上游同时打印日志和错误。注意这里我故意把cache写在forward前面——虽然 coreDNS 会按插件注册的固定顺序执行但你在 Corefile 里的书写顺序在多数情况下不影响执行顺序真正决定顺序的是插件在编译时注册的优先级。这一点常被误解我实测确认过Corefile 里插件书写顺序基本不影响执行顺序执行顺序由插件自身的注册顺序决定。所以你不用纠结cache 要不要写在 forward 前面但你要知道 cache 天然就在 forward 之前生效。一个推荐的通用顺序模板按实际生效顺序理解阶段典型插件作用前置拦截hosts、template本地记录、自定义应答缓存cache缓存上游结果降低延迟转发forward、proxy把请求交给上游观测log、errors、prometheus日志、错误、指标兜底whoami、health健康检查、调试注意health和ready这类插件是给探针用的别和业务解析逻辑混在一起理解它们只回答我活着吗。3.2 缓存插件的参数怎么定cache是性能调优的第一杠杆但参数拍脑袋定很容易出问题。它的核心参数是 TTL 上限写法如cache 30表示最长缓存 30 秒。这里有个容易踩的坑缓存 TTL 不能超过上游记录本身的 TTLcoreDNS 会取两者较小值。所以你把 cache 设成 300但上游记录 TTL 只有 5实际还是 5 秒过期。那 TTL 设多少合适我的经验是按服务变更频率来定。服务地址频繁变动的环境TTL 设短比如 5 到 30 秒保证变更尽快生效相对稳定的环境可以设长60 到 300 秒降低上游压力。但别设太长否则服务扩缩容后旧地址还在缓存里会出现服务明明起来了却访问不到的诡异现象。我一般从 30 秒起步观察一段时间再调。还有一个参数是prefetch它会在缓存条目快过期时提前刷新适合高频访问的域名能避免缓存刚过期瞬间的查询抖动。写法是cache 30 { prefetch 5 10m 10% }含义是当某域名 10 分钟内被请求超过 10 次、且剩余 TTL 低于 10% 时提前刷新。这个参数对稳定性要求高的场景很有用但会增加上游查询量按需开启。3.3 forward 与上游选择forward决定请求最终去哪。写法forward . 8.8.8.8表示所有域名转发到该地址。实际生产里更常见的是按域名分流.:53 { forward example.internal 10.0.0.10 forward . /etc/resolv.conf }第一行把内部域名转到内网 DNS第二行其余走系统解析配置。这种分流的价值在于内部域名不出网、外部域名正常解析既安全又高效。上游选择上有几个实操要点。一是多上游要写多个地址coreDNS 会在它们之间做负载和故障转移写法forward . 8.8.8.8 1.1.1.1。二是注意上游的响应策略默认是随机选一个如果某个上游不稳定可以配合policy参数调整。三是别把上游写成自己形成环路会导致解析彻底挂掉这个错误我在早期配置时犯过表现为所有解析超时排查了很久才发现是转发目标指回了本机。3.4 插件 hosts 与 template 的妙用hosts插件让你像改本机 hosts 文件一样给 coreDNS 加静态记录写法hosts { 10.0.0.5 api.internal fallthrough }fallthrough很关键它表示这条记录没匹配上就继续往后走不加的话没匹配的请求会被直接拒绝。这个细节坑过不少人——加了 hosts 却没加 fallthrough结果所有其它域名都解析失败。template插件更灵活可以按模式动态生成应答适合做简单的自定义解析逻辑。比如给一批内部域名统一返回某个地址。它的语法稍复杂但胜在不用改代码就能实现规则化应答。我一般只在确实需要按规则批量应答时才用它简单静态记录用 hosts 就够了别为了炫技把配置搞复杂。3.5 观测类插件别省log、errors、prometheus这三个插件我建议默认都开。log打印每次查询排查时是救命稻草errors单独收集错误避免错误被淹没prometheus暴露指标配合监控能看到 QPS、缓存命中率、上游延迟这些关键数据。有人担心log影响性能确实高频场景下日志量很大。折中做法是用log的过滤能力只记录特定域名或特定响应码比如只记错误。我的习惯是平时开 errors 和 prometheus排查期临时开 log问题定位完就关掉。这样既保证可观测性又不给生产添负担。4. 实操过程与核心环节实现4.1 从零部署一套 coreDNS先讲独立部署不依赖任何编排平台这样你能看清它最本质的形态。准备一台机器下载对应平台的 coreDNS 二进制写一个最小 Corefile.:53 { forward . 8.8.8.8 1.1.1.1 cache 30 log errors prometheus :9153 health :8080 }启动命令./coredns -conf Corefile。启动后验证用dig 127.0.0.1 example.com查询能拿到应答就说明通了。health插件暴露在 8080 端口curl http://127.0.0.1:8080/health返回 ok 表示服务健康。prometheus在 9153 端口暴露指标可以接监控。这里有个部署细节53 端口是特权端口非 root 运行需要额外授权。生产环境我倾向于用容器方式跑把端口映射处理好避免直接给二进制提权。容器化部署时把 Corefile 挂载进去镜像用官方精简镜像即可启动参数指向挂载路径。4.2 在集群环境里的部署要点集群里部署 coreDNS核心是让它能读到服务信息、能被 Pod 正确指向。典型做法是以 Deployment 形式跑多个副本配一个 Service 暴露 53 端口然后把集群的 DNS 配置指向这个 Service 地址。副本数别只开一个我建议至少两个并且配合反亲和性打散到不同节点——单副本一旦所在节点故障整个集群的解析都会受影响这个故障面太大了。资源配置上coreDNS 本身很轻但要注意内存限制别设太小。缓存会占内存限制过紧会导致频繁驱逐甚至 OOM。我一般给每个副本 128Mi 到 256Mi 的起步内存观察实际用量再调。CPU 方面请求量大的集群要给足否则高 QPS 下会出现排队延迟。还有一个容易被忽略的点coreDNS 的探针配置。liveness 探针打 health 端口readiness 探针打 ready 端口两者别配反。我见过把 readiness 配成 health 端口的结果服务还没准备好就被判定就绪流量打进来解析失败。正确做法是 liveness 用/healthreadiness 用/ready。4.3 一个带分流的完整 Corefile 示例下面这份配置是我在一个混合环境里实际用过的简化版兼顾内部解析、外部转发和可观测性.:53 { errors health :8080 ready :8181 prometheus :9153 hosts { 10.0.0.5 api.internal fallthrough } cache 30 { prefetch 5 10m 10% } forward internal.example 10.0.0.10 forward . 8.8.8.8 1.1.1.1 log . { class denial error } }逐段说明errors收集错误health和ready给探针用prometheus暴露指标hosts加一条静态记录并 fallthroughcache开 30 秒缓存并启用预取两条forward做内外分流log只记录被拒绝和错误的查询控制日志量。这份配置可以直接拿去改改就用域名和地址换成你自己的即可。4.4 验证与压测部署完别急着上线先做两件事。一是功能验证分别查内部域名、外部域名、不存在的域名确认返回符合预期。内部域名应该命中 hosts 或内网转发外部域名正常解析不存在的域名返回 NXDOMAIN 而不是超时。二是压测用 DNS 压测工具打一轮观察 QPS、延迟和缓存命中率。缓存命中率低说明 TTL 太短或查询太分散延迟高要看是不是上游慢。压测时重点看prometheus指标里的缓存命中率和上游请求延迟。我实测下来合理配置缓存后命中率通常能到七八成以上上游压力明显下降。如果命中率很低先检查是不是每个查询的域名都不同比如带随机子域那种场景缓存天然无效得从业务侧优化。5. 常见问题与排查技巧实录5.1 解析超时与随机失败这是最高频的问题表现是 Pod 里访问服务时好时坏日志里出现解析超时。排查思路按链路走先确认 coreDNS 副本是否健康、是否够用再看是不是缓存 TTL 太长导致旧地址然后查上游是否可达最后看网络策略有没有拦截 DNS 流量。一个经典原因是并发查询被上游限流。coreDNS 默认对同一上游的并发查询有限制高 QPS 下超出部分会排队甚至超时。解决办法是增加上游数量、调大并发参数或者优化缓存降低上游压力。我遇到过一次业务侧短时间大量新域名查询把上游打满加了缓存和预取后明显缓解。5.2 服务名解析不到服务明明存在却解析不到先分清是名字格式不对还是数据没同步。名字格式上完整格式是服务名.命名空间.svc.集群域少一段可能就解析不到。数据同步上coreDNS 依赖集群 API 拿服务信息如果 API 访问异常或者 Endpoint 没就绪解析就会失败。排查时我会先在 coreDNS 所在环境直接查一次完整域名确认 coreDNS 本身能不能解析能解析说明问题在调用方比如命名空间不对不能解析再往 API 和 Endpoint 方向查。这个先隔离 coreDNS 自身的思路能省很多时间。5.3 缓存导致的服务已更新但访问旧地址服务扩缩容或重建后地址变了但调用方还在访问旧地址十有八九是缓存 TTL 太长。短期办法是重启 coreDNS 清缓存粗暴但有效长期办法是把 TTL 调短或者对变更频繁的服务单独用更短的 TTL。这里没有银弹本质是缓存一致性和上游压力之间的权衡按业务对变更生效速度的要求来定。5.4 常见问题速查表现象可能原因排查动作处理建议解析随机超时副本不足、上游限流看副本数、上游延迟指标加副本、加缓存、扩上游服务名解析不到名字格式错、Endpoint 未就绪直接查完整域名隔离修正格式、检查服务状态访问旧地址缓存 TTL 过长查缓存配置调短 TTL 或清缓存所有解析失败转发环路、上游不可达检查 forward 目标修正上游、避免指回自身加了 hosts 后其它域名失效缺 fallthrough检查 hosts 配置补 fallthrough高 QPS 下延迟飙升CPU 不足、缓存命中低看 CPU 和命中率加资源、优化缓存5.5 几条踩坑心得第一别在 Corefile 里写自己解析不了的转发目标环路问题排查成本极高配置前先想清楚数据流向。第二hosts 插件一定记得 fallthrough这个坑几乎每个新手都会踩一次。第三探针端口别配反liveness 和 readiness 用错端口会导致流量在服务未就绪时涌入。第四缓存 TTL 是双刃剑调优前先想清楚业务对变更生效速度的容忍度。第五日志按需开生产常开全量日志既费磁盘又影响性能用过滤只记关键信息。我个人在实际操作中的体会是coreDNS 的配置本身不难难的是理解它在整条服务发现链路里的位置。很多所谓的coreDNS 问题根子其实在服务状态、网络策略或者调用方配置。把数据流向在脑子里画清楚——请求从 Pod 出发经过 coreDNS再到上游或集群 API——排查时顺着这条线一段段验证绝大多数问题都能快速定位。这套思路比记住任何单个参数都值钱。