在 Kubernetes 里介绍 CoreDNS，常见说法很短：它是集群的 DNS 服务器。这句话能帮助入门，也会遮住项目内部更值得看的设计。[1][2][4] CoreDNS 手册说得很直白：服务器依靠插件工作，大部分 DNS 能力都放在插件里，而不是焊成一块单体二进制。[2] 配置文档接着补上一条很容易漏掉的规则：Corefile 里的书写顺序不决定插件执行顺序；链路顺序来自 plugin.cfg。所以 Corefile 看上去灵活，运行时仍然受一张预先编译好的插件图约束。[3]
把这个前提带进 CNCF 的 Understanding CoreDNS in Kubernetes，整场视频会清楚很多。[1] 它的价值不只是复述 DNS 基础，也不只是演示 Kubernetes 配置。讲者反复说明的是一件更具体的事：CoreDNS 里有一组插件负责已知名字范围，其他插件围着这组回答补充行为；范围外的名字会被交给别的解析器。[1][3][4][5]
今天的官方文档仍然支持这种读法。手册用插件组合来定义 CoreDNS。[2] 配置页解释 server block、directives 与编译期插件顺序。[3] kubernetes 插件页面则说明，这个插件会 watch Kubernetes 对象，只回答自己配置负责的 zone；查询落到负责范围之外时，再由 forwarding 或 fallthrough 处理。[4] 视频和文档放在一起看，CoreDNS 更像一台职责清楚的插件服务器，而不是一个会自动吞下所有命名问题的“集群 DNS 盒子”。[1][3][4]
带着这个视角回看视频，很多细节就不再零散。watch 循环说明集群内事实从哪里来，上游解析器的交接说明查询到哪里离开 CoreDNS，pod 回答模式和编译期插件顺序则说明，CoreDNS 从一开始就不打算把自己做成随意改写请求路径的动态脚本环境。[1][2][3][4]
配图说明：题图使用 John Belamaric 的真实 GitHub 头像。这个选择合适，因为本文围绕的是维护者对 CoreDNS 内部机制、插件职责和查询路径的讲解。最重要的视觉锚点，是解释系统的人，而不是通用服务器照片或人为拼接的 DNS 示意图。[6]
大约从 4:19 开始，“集群 DNS” 很快落到 CoreDNS 里的 Kubernetes service discovery
视频前段最值得停一下的地方，是讲者提到 CoreDNS 原生支持 Kubernetes service discovery，并说明它后来成了 Kubernetes 1.13 的默认 DNS 服务器。[1] 这句话看上去像背景介绍，实际已经把项目位置说得更准。重点不在 CoreDNS 恰好跑在 Kubernetes 旁边，而在 Kubernetes 命名这件事由一个明确的插件放进 CoreDNS 里。[1][4]
kubernetes 插件页面用更冷静的语言说的是同一件事。这个插件实现 Kubernetes DNS-Based Service Discovery 规范，可以替代 kube-dns，并对自己配置负责的 zone 给出权威回答。[4] 这比“CoreDNS 知道整个集群的所有名字”收得更紧。它知道的是这组 zone 与对象类型之内的命名事实。手册对 CoreDNS 的总定义又把原因补齐：插件才是 DNS function 的单位，所以 Kubernetes 支持是一块由插件定义出来的回答范围。[2]
这正是视频前段最有价值的地方。它让 Kubernetes 里的 CoreDNS 不再只是“默认组件”那种平铺描述。CoreDNS 并不天然等同于那只 DNS Pod；它是一台插件化 DNS 服务器，Kubernetes 则是其中很重要的一块权威数据来源。[1][2][4]
大约从 8:32 与 13:58 开始，watch 到的集群状态和上游递归解析被分开
下一段把查询路径讲清的地方，出现在讲者说明 CoreDNS 会连接 Kubernetes API、watch Services、Pods 与 Endpoints，回答属于集群内部的名字，再把范围外的查询转交给上游解析器的时候。[1] 这几分钟几乎把排障时的分界线说完了：集群内服务发现来自 watch；集群外命名交给上游 DNS。[1][4]
文档与视频在这里几乎完全重合。kubernetes 插件页面说明，插件可以在集群内连接 API，也可以连接远端 API server，还明确写出 stubDomains 与 upstreamNameservers 是通过 forward 插件实现的。[4] 同一页还说，这个插件在一个 server block 里只能使用一次。这条规则的分量很大，因为它提醒你，这块回答范围在设计上就要保持可读，不能在一个逻辑服务器里无限复制。[4] 配置文档从另一侧把这种克制固定下来：一个 server block 定义的是面向某个 zone 的插件链，而不是一团随时变形的运行时脚本。[3]
这也是 forwarding 在这场视频里如此重要的原因。它不是服务发现之后顺手带上的补丁功能，它就是那条交接线。CoreDNS 没有假装 Kubernetes 是通用命名权威。它只对 cluster-local 的知识负责，再把其余查询交给上游 DNS。记住这条线，很多排障问题会简单很多：一个名字要么属于被 watch 的集群 zone，要么已经进入 forwarding 路径。[1][4]
大约从 22:55 开始，kubernetes 插件选项把严格之处摆到台面上
视频后段 John Belamaric 讲到 kubernetes 插件几个常见选项时，前面的架构判断落到了具体配置上。[1] 他解释了 service 子域、独立的 pod 命名空间，以及 kube-dns 过去那种“只要看起来像 IP 地址就回一个结果”的宽松做法。接着视频指出，CoreDNS 给出了更严格的模式：运维者可以把 pod 回答完全关掉，也可以要求系统只在目标 pod 真实存在于该 namespace 时才给出结果。[1]
当前文档把这些模式写得很清楚。pods disabled 会返回 NXDOMAIN；pods insecure 会直接回显请求里的 IP；pods verified 只有在对应 pod 存在时才回答，同时会带来更高的内存成本，因为 CoreDNS 需要维护针对全部 pod 的 watch。[4] 页面还列出了 endpoint_pod_names、noendpoints、namespace 过滤、label 过滤，以及默认 5 秒 TTL 这些行为。[4] 它们都在调节同一件事：回答范围可以收紧或放宽，成本必须写在明处。
所以这段视频最重要的地方，不只是“这里有几个 knob 可以调”。它在说明 CoreDNS 怎样看待可信回答。kube-dns 那种宽松回应方式当然方便，CoreDNS 则要求运维者明确选择：你要便利，还是要可验证的回答和看得见的资源成本。[1][4]
大约从 26:17 开始，连插件灵活性本身也受编译期顺序约束
整场视频最锋利的一个时刻，出现在讲者提醒观众：默认镜像会把一组插件编译进去，这些插件不是运行后再动态装载的，连顺序也在编译期就定下来了。[1] CoreDNS 配置文档把这一点写得没有歧义：Corefile 中插件的书写顺序不决定执行顺序；顺序由 plugin.cfg 决定。[3]
这条规则很容易被忽略，却正好把整个系统收拢起来。CoreDNS 显得很灵活，是因为 Corefile 很短，插件目录又很大。[2][5] 插件页把 in-tree 模块列成一张近乎菜单式的目录，这种感觉会更强。[5] 视频与文档放在一起读，就会发现这份灵活性一直有上限。CoreDNS 不能在运行时任意重排内部结构。编译出来的插件图先定义能执行的范围，Corefile 再在这个范围里选择并配置具体行为。[1][3][5]
这也是这支视频今天仍值得看的原因。它把 CoreDNS 讲得很老实。Kubernetes 服务发现来自 watch 状态，不来自魔法。集群外命名通过上游解析器处理，不落在集群负责范围里。pod 回答模式是一种策略选择，带着明确代价。连那套著名的插件模型，也始终受编译期顺序约束，好让请求路径保持可预测。[1][2][3][4][5] 沿着这些线索理解 CoreDNS，它就不再只是 Kubernetes 默认件，而会显露出更准确的形状：一台由插件组成、职责有限、顺序受控的 DNS 服务器。
来源
- CNCF，《Understanding CoreDNS in Kubernetes - John Belamaric, Google & Cricket Liu, Francois Tur, Infoblox》，YouTube 视频，发布于 2018 年 12 月 16 日。
- CoreDNS Manual，《What is CoreDNS?》——以插件为中心定义服务器与 DNS function。
- CoreDNS Manual，《Configuration》——Corefile 结构、server block，以及通过
plugin.cfg确定编译期插件顺序的规则。 - CoreDNS documentation，《
kubernetesplugin》——zone 权威范围、watch 行为、pod 模式、TTL 默认值与 forwarding 说明。 - CoreDNS documentation，《Plugins》——in-tree 插件目录与当前项目插件列表。
- GitHub，《johnbelamaric》——本文配图来源页面。