2. CoreDNS 架构基础：组件架构、插件机制、数据流与请求处理路径
CoreDNS 是 Kubernetes 集群的默认 DNS 组件，采用 链式插件 架构设计。理解其内部组件、插件加载机制以及请求处理路径，是诊断 DNS 超时故障和进行扩缩容优化的前提。
2.1 CoreDNS 组件架构
CoreDNS 以单一二进制文件运行，内部由 核心引擎 (Core)、插件注册表 (Plugin Registry) 和 DNS 中间件链 (Middleware Chain) 三部分组成。核心引擎负责启动监听、管理配置；插件注册表维护所有已注册的插件；中间件链则按 Corefile 中定义的顺序串联插件，形成请求处理管道。
核心组件表：
| 组件 | 职责 | 关键特性 |
|---|---|---|
| Core 引擎 | 启动 UDP/TCP 监听、加载 Corefile、初始化插件链 | 支持多端口监听、TLS 终止 |
| 插件注册表 | 管理所有内置与外部插件的注册与初始化 | 插件通过 init() 自动注册 |
| 中间件链 | 按 Corefile 顺序串联插件，形成请求处理管道 | 每个插件可决定是否将请求传递给下一个插件 |
| 缓存插件 | 缓存 DNS 响应，减少上游查询压力 | 支持正反向缓存、预取、TTL 覆盖 |
| 转发插件 | 将未匹配的请求转发至上游 DNS 服务器 | 支持轮询、最快响应、强制 TCP |
2.2 插件机制与 Corefile 配置
CoreDNS 的插件机制是其灵活性的核心。每个插件实现一个 DNS 中间件接口，通过 Corefile 配置文件决定启用哪些插件及其顺序。插件按功能可分为三类：
- 服务插件：提供 DNS 服务本身，如
kubernetes、file、hosts。 - 处理插件：修改或增强 DNS 请求/响应，如
cache、rewrite、template。 - 观测插件：暴露指标、健康检查、日志，如
prometheus、health、log。
关键原则：插件顺序决定处理逻辑。例如
cache 应放在 forward 之前，以优先命中缓存减少上游查询；loop 应放在链尾，用于检测转发循环。
典型的 Kubernetes 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
cache {
success 10000 30
denial 5000 5
}
forward . /etc/resolv.conf {
max_concurrent 1000
}
reload
loop
}2.3 请求处理路径与数据流
当 Pod 发起 DNS 查询时，请求经过以下完整路径：
- Pod → Service IP：Pod 的
/etc/resolv.conf指向kube-dnsService IP（通常为10.96.0.10）。 - Service → Endpoint：kube-proxy 将请求转发至 CoreDNS Pod 的
53端口（UDP/TCP）。 - Core 引擎接收：Core 引擎解析 DNS 报文，进入插件链。
- 插件链处理：按顺序执行
errors→health→kubernetes→cache→forward→loop。 - 响应返回：插件链处理完成后，响应沿原路径返回至 Pod。
2.4 关键数据流特性
- UDP 优先，TCP 回退：CoreDNS 默认使用 UDP 处理 DNS 请求，当响应超过 512 字节（EDNS0 协商）或遇到截断标志时，自动回退至 TCP。
- 并发与超时：
forward插件支持max_concurrent限制并发查询数，超时默认 5s，可通过expire参数调整。 - 缓存命中与失效：
cache插件根据 TTL 缓存正向和否定响应，缓存满时采用 LRU 淘汰策略。 - 健康检查与就绪：
health插件暴露/health端点，ready插件暴露/ready端点，用于 Kubernetes 存活/就绪探针。
常见陷阱：如果
forward 插件的 max_concurrent 设置过小（如默认 1000），在高并发场景下会导致查询排队超时，表现为 DNS 解析延迟飙升。这是后续扩缩容优化的关键切入点。