企业官网建设流程全解析

DNS 这东西，平时没人注意它，一旦出问题，整个集群就像断了线的风筝——服务明明活着，就是互相找不到。我最早接触 coreDNS 是在一个自建的小集群里，当时服务间调用时通时不通，排查了大半天才发现是 DNS 解析超时导致的。从那以后我花了不少时间把 coreDNS 的配置、插件链、缓存机制和排错方法摸了一遍。这篇内容就是把这些年踩过的坑和验证过的配置整理出来，适合正在用容器编排平台、需要自己维护集群内域名解析的运维和开发同学，也适合刚接触 coreDNS、想搞明白它到底怎么运转的朋友。读完你至少能搞清楚三件事：coreDNS 的请求是怎么一步步被处理的、Corefile 里那些插件到底谁先谁后、以及解析出问题时该从哪儿下手查。

1. coreDNS 到底在集群里扮演什么角色

很多人第一次看到 coreDNS，是在集群里发现有个叫kube-dns的 Service，后面挂着一组 coreDNS 的 Pod。名字叫 kube-dns，实际跑的却是 coreDNS，这个历史遗留的命名让不少人困惑。要理解 coreDNS 的定位，得先搞清楚集群里的 DNS 解析到底解决什么问题。

1.1 从一次服务调用失败说起

假设你在集群里部署了两个服务，服务 A 要调用服务 B，代码里写的是http://service-b.default.svc.cluster.local。这个域名在集群外根本不存在，只有集群内部的 DNS 才能解析。当 A 发起请求时，它的 DNS 查询会先被节点的解析配置指向 coreDNS 的 ClusterIP，coreDNS 收到查询后，根据配置的插件链去查对应的 Service 记录，返回一个 ClusterIP 或者 Pod IP，A 才能拿到地址发起真正的连接。

这个过程听起来简单，但里面有几个关键点：第一，coreDNS 本身也是跑在集群里的 Pod，它怎么保证自己高可用；第二，它怎么知道某个 Service 对应哪个 IP；第三，外部域名（比如访问公网 API）的查询它又怎么处理。这三个问题分别对应了 coreDNS 的部署形态、Kubernetes 插件和 forward 插件。我见过不少团队在集群刚搭起来时没关注这些，等到服务规模上来，DNS 查询量一大，问题就集中爆发了。

提示：集群里那个叫kube-dns的 Service 是给业务 Pod 用的解析入口，它的 ClusterIP 会被写进每个 Pod 的/etc/resolv.conf，所以别看到名字就以为是老组件，实际后端是 coreDNS。

1.2 coreDNS 和传统 DNS 服务的本质区别

传统 DNS 服务比如 BIND，配置是一堆 zone 文件，改一条记录要动文件、reload 服务。coreDNS 完全换了个思路：它把 DNS 服务拆成一条插件链，每个插件负责一类查询的处理逻辑，请求进来后沿着插件链依次经过，谁匹配上谁处理。这种设计的好处是扩展性极强，想加个自定义解析逻辑，写个插件挂上去就行；坏处是插件顺序错了，行为就完全不对，而且这种错误往往很隐蔽。

举个直观的例子，cache插件放在kubernetes插件前面和后面，效果完全不同。放前面，缓存的是最终解析结果；放后面，缓存的是 kubernetes 插件查出来的结果。大部分场景下我们希望缓存最终结果，所以cache一般靠前。这种"顺序即逻辑"的设计，是理解 coreDNS 的第一道门槛，也是后面配置排错的核心线索。

1.3 一个请求在 coreDNS 内部的完整旅程

把一次 DNS 查询想象成进了一栋办事大厅。请求从Server块进来，先经过最外层的插件，比如errors负责记录错误、log负责打日志，然后进入cache看有没有现成答案，有就直接返回，没有就继续往下走。接着到kubernetes插件，它判断这个域名是不是集群内的服务域名（通常是cluster.local后缀），是的话就去 API 里查对应的 Service 或 Endpoint 记录；不是的话就交给forward插件，转发给上游 DNS 服务器。

这个流程里每一步都可能出问题：cache的 TTL 设太短导致查询量下不去，kubernetes插件的pods模式配置不当导致解析到已销毁的 Pod，forward的上游地址写错导致外部域名全挂。我在实际维护中总结出一条经验：coreDNS 的问题八成出在插件顺序和插件参数上，剩下一成半是上游网络，最后半成才是 coreDNS 自身 bug。所以排查时先看 Corefile，再看网络，最后才怀疑组件本身。

2. Corefile 的写法与插件链的排序逻辑

Corefile 是 coreDNS 的核心配置文件，语法看起来像 nginx 的配置块，但里面的门道不少。很多人照着模板抄一份能跑起来，但一旦要加自定义逻辑就懵了，根本原因是没搞懂 Server 块和插件链的关系。

2.1 Server 块决定了"谁来处理哪类请求"

Corefile 的基本结构是若干个 Server 块，每个块以域名:端口开头，大括号里是插件列表。比如：

.:53 { errors health ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } forward . /etc/resolv.conf cache 30 loop reload loadbalance }

这个块的意思是：监听 53 端口，处理所有域名（.表示根域）的查询。里面的插件从上到下构成处理链。注意kubernetes插件后面跟的cluster.local in-addr.arpa ip6.arpa是它负责的域名后缀，只有这些后缀的查询才会进这个插件，其他的会fallthrough到后面的forward。

这里有个容易踩的坑：如果你有多个 Server 块，coreDNS 会根据请求的域名和端口匹配最具体的那个块。比如你有一个.:53的块和一个cluster.local:53的块，那么cluster.local后缀的查询会优先匹配后者。这个匹配规则和插件的fallthrough是两套机制，混在一起理解很容易出错。我的建议是初期只用一个.:53块，把所有逻辑放在里面，等确实有性能隔离需求再拆块。

2.2 插件顺序不是随便排的

插件链的执行顺序就是它们在 Corefile 里出现的顺序，但这个顺序不是完全自由的，coreDNS 内部对某些插件有固定的排序约束。比如cache插件如果放在kubernetes后面，它缓存的就是 kubernetes 的查询结果，这在多数场景下没问题；但如果放在forward后面，那外部域名的查询结果也会被缓存，这通常也是期望的行为。真正需要注意的是loop插件，它必须放在靠前的位置，用来检测转发环路，放太后面可能检测不到。

我整理了一份常见插件的推荐顺序，供参考：

这张表不是死规矩，但按这个顺序排，绝大多数场景不会出问题。我见过有人把forward放在kubernetes前面，结果集群内域名全被转发到上游，上游当然不认识cluster.local，直接返回 NXDOMAIN，服务间调用全挂。这种错误排查起来很费劲，因为日志里只看到 NXDOMAIN，看不出是顺序问题。

2.3 fallthrough 与插件匹配的微妙关系

fallthrough是 coreDNS 里一个高频出现但容易误解的指令。它的作用是：当当前插件无法处理某个查询时，把查询交给链上的下一个插件。听起来简单，但实际行为取决于插件的实现。以kubernetes插件为例，它只处理自己配置的后缀（比如cluster.local），对于其他后缀的查询，默认行为是返回 NXDOMAIN 还是 fallthrough，取决于有没有显式配置fallthrough。

我在一个多租户集群里遇到过这样的问题：不同租户用不同的子域名后缀，比如tenant-a.cluster.local和tenant-b.cluster.local。如果kubernetes插件只配置了cluster.local，那么tenant-a.cluster.local的查询会被它匹配到，但它查不到对应记录，默认返回 NXDOMAIN，根本不会走到后面的forward。解决办法是在kubernetes插件里显式加上fallthrough，让查不到的查询继续往下走。这个细节在官方文档里写得不显眼，但实际多租户场景下几乎必踩。

注意：fallthrough后面可以跟具体的后缀列表，表示只对这些后缀的查询做 fallthrough。不写后缀表示对所有查不到的查询都 fallthrough。后者更省事，但可能把本该返回 NXDOMAIN 的查询也放过去，需要根据实际场景权衡。

3. kubernetes 插件：集群内域名解析的核心

kubernetes插件是 coreDNS 在容器编排平台里最重要的插件，没有之一。它负责把集群里的 Service、Endpoint、Pod 信息转换成 DNS 记录。理解它的记录生成规则和几种查询模式，是排查集群内解析问题的关键。

3.1 Service 记录是怎么生成的

当一个 Service 被创建时，kubernetes插件会为它生成几条 DNS 记录。以default命名空间下名为my-svc的 Service 为例，会生成：

• my-svc.default.svc.cluster.local指向 Service 的 ClusterIP（A 记录）
• my-svc.default.svc.cluster.local的 SRV 记录，包含端口信息
• my-svc.default.svc和my-svc.default等短域名形式

这里有个细节：短域名形式（比如my-svc）能不能解析，取决于 Pod 的resolv.conf里的search域配置。默认情况下，Pod 的search域会包含<namespace>.svc.cluster.local、svc.cluster.local、cluster.local这几项，所以同命名空间内直接写my-svc就能解析。跨命名空间调用就得写全my-svc.other-ns.svc.cluster.local，或者至少my-svc.other-ns。

我见过有人抱怨"同命名空间能解析，跨命名空间不行"，排查半天以为是网络策略问题，其实是域名写短了。这种问题在日志里表现为 NXDOMAIN，但根因是 search 域没匹配上。判断方法很简单：进到 Pod 里cat /etc/resolv.conf，看search行有哪些后缀，再对照你写的域名，就知道短域名能不能用了。

3.2 Endpoint 记录与 headless Service 的特殊行为

普通 Service 的 A 记录返回的是 ClusterIP，但 headless Service（clusterIP: None）不一样，它的 A 记录返回的是所有后端 Pod 的 IP 列表。这个行为由kubernetes插件的endpoint相关配置控制。headless Service 常用于有状态服务，比如数据库集群，客户端需要拿到所有节点地址自己做负载均衡或选主。

这里有个坑：headless Service 的 A 记录返回的 Pod IP 列表，顺序是不保证的，而且会随 Pod 的增减动态变化。如果你的客户端代码假设第一个 IP 是主节点，那迟早出问题。正确做法是通过 SRV 记录拿到带权重的列表，或者干脆用专门的服务发现机制。另外，headless Service 的解析结果默认不带 TTL 缓存优化，查询量大时对 coreDNS 压力不小，建议在kubernetes插件里配置合适的 TTL。

3.3 pods 模式的取舍：insecure 还是 verified

kubernetes插件有个pods配置项，控制 Pod 记录的生成方式。可选值有disabled、insecure、verified。disabled表示不生成 Pod 记录；insecure表示生成 Pod 记录但不校验 Pod 是否真的在运行；verified表示生成前会去 API 校验 Pod 状态。

这个选择直接影响解析的准确性和性能。insecure模式下，即使 Pod 已经销毁，只要 API 里还有残留记录（比如删除过程中的短暂窗口），DNS 仍可能返回它的 IP，导致请求打到不存在的地址。verified模式会多一次 API 查询，准确性高但增加延迟和 API 压力。我的经验是：对解析准确性要求高的场景（比如金融类业务）用verified，对性能敏感、能容忍短暂不一致的场景用insecure，而大多数普通业务其实用disabled就够了，因为业务通常通过 Service 访问，不需要直接解析 Pod 域名。

提示：pods模式只影响形如<pod-ip>.<namespace>.pod.cluster.local的记录，不影响 Service 记录。如果你从来没在代码里直接写过 Pod 域名，这个配置改不改影响不大。

4. 缓存、转发与上游：那些让解析变慢或变错的配置

coreDNS 的性能和正确性，很大程度上取决于cache和forward这两个插件的配置。它们看起来简单，但参数背后的逻辑值得细说。

4.1 cache 的 TTL 与 prefetch 怎么调

cache插件的基本用法是cache 30，表示缓存 30 秒。但实际可配的参数远不止 TTL，还有success、denial、prefetch、serve_stale等。其中prefetch和serve_stale是最容易被忽略但最有价值的两个。

prefetch的作用是：当某个域名在 TTL 过期前被查询达到一定次数，coreDNS 会提前异步刷新缓存，避免过期瞬间的查询穿透。配置形式是prefetch 10 60s 10%，意思是 60 秒内被查询 10 次以上，且剩余 TTL 低于 10% 时触发预取。这个配置对高频访问的域名效果明显，能显著降低解析延迟的抖动。

serve_stale的作用是：当上游 DNS 不可达时，返回过期的缓存结果而不是直接报错。配置形式是serve_stale 1h，表示最多返回 1 小时内的过期缓存。这个在跨机房或上游不稳定的场景下非常有用，能避免上游抖动导致整个集群解析失败。我负责的一个集群曾经因为上游 DNS 短暂不可用，导致所有外部 API 调用失败，加上serve_stale后这类故障的影响面小了很多。

4.2 forward 的上游选择与策略

forward插件负责把非集群域名的查询转发给上游。最常见的写法是forward . /etc/resolv.conf，表示使用节点上的 resolv.conf 里的上游服务器。这个写法在大多数环境里能用，但有个隐患：节点的 resolv.conf 可能被其他配置修改，导致上游地址变化。更稳妥的做法是显式写上游地址，比如forward . 8.8.8.8 1.1.1.1，或者指向内网的自建 DNS。

forward还支持策略配置，比如policy random、policy round_robin、policy sequential。默认是random，在多上游场景下能分散压力。如果上游有主备关系，用sequential更合适，它会按顺序尝试，主挂了才用备。另外health_check参数可以配置健康检查，自动剔除不可用的上游，这个在生产环境建议开启，配置形式是health_check 5s。

4.3 上游解析失败的典型表现与定位

上游解析失败在业务侧的表现往往是"偶发超时"或"部分域名解析不了"。定位时先看 coreDNS 的日志，如果开了log插件，能看到每个查询的响应码。SERVFAIL通常表示上游不可达或超时，NXDOMAIN表示域名不存在（可能是真的不存在，也可能是上游配置问题），REFUSED表示上游拒绝查询（常见于上游有访问控制）。

我排查这类问题的固定套路是：先在 coreDNS Pod 里用dig @127.0.0.1 example.com直接查本地，确认 coreDNS 自身是否正常；再用dig @<上游IP> example.com直接查上游，确认上游是否可达；最后对比两者结果，就能定位是 coreDNS 配置问题还是上游网络问题。这个三步法看起来笨，但比盲目看日志高效得多。

5. 解析出问题时的排查链路

DNS 问题的特点是"现象在业务，根因在配置或网络"，排查时最忌讳一上来就改配置。我总结了一条从现象到根因的排查链路，按这个顺序走，大部分问题能在十分钟内定位。

5.1 第一步：确认 Pod 的 resolv.conf 是否正确

所有解析问题的排查都应该从 Pod 内部开始。进到出问题的 Pod 里，cat /etc/resolv.conf，重点看三行：nameserver是不是 coreDNS 的 ClusterIP，search域是否包含预期的后缀，options ndots是多少。ndots这个参数很关键，它决定了域名在尝试绝对解析前会先拼接多少个 search 后缀。默认是 5，意味着如果一个域名里点的数量少于 5，会先尝试拼接 search 后缀，这可能产生大量无效查询。

比如你查api.example.com，它有两个点，小于 5，那么 coreDNS 会先收到api.example.com.default.svc.cluster.local、api.example.com.svc.cluster.local等一串查询，全部 NXDOMAIN 后才查api.example.com本身。这不仅增加延迟，还让 coreDNS 日志里充满无效查询。解决办法是在 Pod 的dnsConfig里把ndots调小，比如设为 2，或者查询时在域名末尾加个点表示绝对域名。

5.2 第二步：在 coreDNS 侧验证解析结果

确认 Pod 的 resolv.conf 没问题后，进到 coreDNS Pod 里直接查。用dig @127.0.0.1 <目标域名>，看返回结果是否符合预期。如果这里能解析但 Pod 里不能，问题在 Pod 到 coreDNS 的网络链路上，可能是网络策略、Service 的 Endpoint 异常，或者 kube-proxy 规则问题。如果这里也不能解析，问题在 coreDNS 配置或上游。

这一步的关键是区分"coreDNS 自身能不能解析"和"Pod 能不能通过 coreDNS 解析"。前者查配置，后者查网络。我见过不少案例是 coreDNS 配置完全正确，但 Pod 的nameserver指向了一个已经失效的旧 ClusterIP，导致所有解析超时。这种问题在集群重建或 coreDNS Service 重建后特别容易出现。

5.3 第三步：看插件链是否按预期执行

如果 coreDNS 自身解析也不对，就要看插件链了。最直接的方法是临时在 Corefile 里加log插件，观察查询经过了哪些插件、最终由谁响应。log插件的输出格式里会带上响应码和处理的插件名，能快速定位是kubernetes插件没匹配上，还是forward转发失败。

另一个技巧是用dig的+trace参数，虽然它主要用来追踪公网 DNS 解析路径，但在 coreDNS 场景下也能看出查询在哪个环节断了。不过+trace对 coreDNS 的插件链支持有限，更可靠的方式还是看log输出。我一般会在排错时临时把log和errors都打开，问题定位后再关掉，避免日志量过大影响性能。

5.4 第四步：检查上游与网络连通性

如果插件链执行正常但结果不对，就要怀疑上游了。在 coreDNS Pod 里dig @<上游IP> <域名>，确认上游是否可达、是否返回正确结果。如果上游不可达，检查网络策略、防火墙规则、路由表。如果上游可达但结果不对，检查上游的配置，或者确认是不是被中间设备劫持了查询。

这里有个容易被忽略的点：coreDNS 的forward插件默认会继承节点的 DNS 配置，如果节点本身配置了多个上游，coreDNS 会随机选一个。如果其中一个上游有问题，就会出现"时好时坏"的现象。解决办法是显式指定可靠的上游，或者开启health_check自动剔除故障上游。

6. 生产环境下的稳定性配置经验

把 coreDNS 跑起来不难，难的是让它在大流量、多变更的环境下稳定运行。这一节分享几个我在生产环境里验证过的配置和做法。

6.1 资源限制与副本数的权衡

coreDNS 的资源消耗主要来自查询量和缓存大小。一个中等规模的集群（几百个 Pod），单个 coreDNS 实例给 100m CPU 和 70Mi 内存通常够用。但要注意，coreDNS 是延迟敏感型服务，CPU 限制太低会导致查询排队，表现为解析延迟抖动。我的经验是 CPU 限制不要低于 100m，内存不要低于 70Mi，副本数至少 2 个，并且配置反亲和性让它们分散到不同节点。

副本数的选择还要考虑故障域。如果集群跨多个可用区，coreDNS 副本应该每个区至少一个，避免某个区网络隔离时该区的 Pod 全部解析失败。另外，coreDNS 的 Service 默认是 ClusterIP 类型，kube-proxy 会在每个节点上做负载均衡，所以副本数不需要和节点数一一对应，但副本太少会导致单点压力过大。

6.2 监控指标里最该关注的几个

coreDNS 暴露的 Prometheus 指标里，有几个是必须配告警的。coredns_dns_request_duration_seconds的 P99 延迟，超过 100ms 就说明有性能问题；coredns_dns_responses_total按响应码分类，SERVFAIL比例超过 1% 就要关注；coredns_cache_hits_total和coredns_cache_misses_total的比值反映缓存效果，命中率低于 80% 说明缓存配置可能有问题。

还有一个容易被忽略的指标是coredns_forward_healthcheck_failures_total，它反映上游健康检查的失败次数。这个指标持续增长说明上游不稳定，即使当前解析还正常，也应该提前处理。我一般会把这个指标和serve_stale配合使用，上游失败时先靠过期缓存顶着，同时告警通知人去修上游。

6.3 配置变更的安全流程

Corefile 的变更风险很高，一个插件顺序调整就可能让整个集群解析异常。我的做法是：所有 Corefile 变更先在一个测试集群验证，验证通过后再走灰度。灰度的方法是先改一个 coreDNS 副本的 ConfigMap，观察一段时间（至少 10 分钟）的解析成功率和延迟，没问题再全量。coreDNS 的reload插件支持配置热加载，改完 ConfigMap 后大约 30 秒生效，不需要重启 Pod，这给灰度提供了便利。

另外，Corefile 一定要纳入版本管理，每次变更记录变更原因和验证结果。我经历过一次事故，某次为了临时解决一个问题加了个插件，事后忘了删，几个月后这个插件和新加的配置冲突，导致解析间歇性失败。从那以后我们规定所有临时配置必须带注释和过期时间，定期清理。

注意：reload插件虽然方便，但它只监控 Corefile 的变化，不监控 Corefile 里引用的外部文件（比如通过import引入的配置）。如果用了import，改被引入的文件不会触发 reload，需要手动重启或 touch 一下 Corefile。

7. 几个真实场景下的配置片段

光讲原理不够直观，这一节放几个我在实际环境里用过的配置片段，每个都附上适用场景和注意事项，可以直接参考。

7.1 单集群标准配置

这是最通用的配置，适合大多数单集群场景：

.:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } forward . /etc/resolv.conf { max_concurrent 1000 health_check 5s } cache 30 { success 60 denial 30 prefetch 10 60s 10% serve_stale 1h } loop reload loadbalance }

几个关键点：health的lameduck 5s让 Pod 在退出前继续服务 5 秒，避免滚动更新时的解析中断；forward的max_concurrent 1000限制并发转发数，防止上游被打爆；cache的serve_stale 1h在上游故障时兜底。这套配置我在多个集群用过，稳定性不错。

7.2 多租户场景的域名隔离

多租户集群里，不同租户的服务域名需要隔离，避免互相解析。做法是用多个 Server 块，每个租户一个后缀：

tenant-a.local:53 { errors kubernetes cluster.local { pods disabled fallthrough } forward . /etc/resolv.conf cache 30 } tenant-b.local:53 { errors kubernetes cluster.local { pods disabled fallthrough } forward . /etc/resolv.conf cache 30 }

这里的关键是每个块只处理自己后缀的查询，fallthrough让查不到的查询继续走forward。注意kubernetes插件里的cluster.local是它负责的域名后缀，和 Server 块的后缀是两回事，别搞混。这种配置下，租户 A 查tenant-b.local的域名会被匹配到tenant-b.local块，实现隔离。

7.3 上游故障时的降级配置

如果上游 DNS 不稳定，可以用serve_stale加health_check做降级：

.:53 { errors health ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } forward . 10.0.0.10 10.0.0.11 { policy sequential health_check 3s max_fails 2 } cache 30 { serve_stale 2h prefetch 5 30s 20% } loop reload }

policy sequential让 coreDNS 按顺序尝试上游，主上游挂了才用备；health_check 3s和max_fails 2让故障上游在 6 秒内被剔除；serve_stale 2h让上游全挂时还能用 2 小时内的过期缓存顶着。这套配置适合上游质量一般但业务不能停的场景。

8. 写在最后的几点个人体会

coreDNS 这个组件，配置看起来简单，但真正吃透需要理解它背后的插件链模型和 DNS 协议本身。我刚开始维护时也走过弯路，比如把cache放在kubernetes后面导致缓存效果差，或者忘了配fallthrough导致多租户域名解析失败。这些坑踩过之后，我形成了一个习惯：每次改 Corefile 之前，先在纸上画出插件链，标出每个查询会经过哪些插件、在哪个插件被处理，画完再动手改。这个笨办法帮我避免了很多低级错误。

另外一个体会是，DNS 问题的排查一定要有耐心，按链路一步步走，不要跳步。我见过太多人一上来就怀疑 coreDNS 有 bug，结果查到最后发现是 Pod 的ndots配置或者网络策略问题。coreDNS 本身其实很稳定，绝大多数问题都出在配置和网络环境上。把排查链路走熟，比记住一堆配置参数更有用。

最后说个实用的小技巧：如果你不确定某个 Corefile 配置的行为，可以用coredns -conf Corefile -dns.port 1053在本地起一个实例，用dig @127.0.0.1 -p 1053测试，完全不碰生产环境。这个本地验证的习惯，能让你在改生产配置前心里有底。