2. CoreDNS 架构速览：组件、插件链、缓存机制与交互关系
CoreDNS 是 Kubernetes 集群默认的 DNS 解析组件，采用 插件链（Plugin Chain） 架构。理解其内部组件、缓存策略以及与 etcd / API Server 的交互，是定位 DNS 异常根因的基础。
2.1 核心组件与插件链
CoreDNS 以单一二进制运行，通过 Corefile 配置插件链。每个插件负责一个独立功能（如缓存、转发、重试），请求按配置顺序流经插件链。
| 组件/插件 | 功能 | 典型配置示例 |
|---|---|---|
| Server | 监听 UDP/TCP 端口（默认 53），接收 DNS 查询 | .:53 { ... } |
| bind | 绑定监听地址，支持多网卡 | bind 0.0.0.0 |
| errors | 将错误日志输出到标准错误 | errors |
| health | 暴露 HTTP /health 端点用于存活检查 | health :8080 |
| ready | 暴露 HTTP /ready 端点用于就绪检查 | ready :8181 |
| prometheus | 暴露 Prometheus 指标（请求量、延迟、缓存命中率） | prometheus :9153 |
| cache | DNS 查询结果缓存，降低上游压力 | cache 30 |
| forward | 将未匹配的查询转发到上游 DNS（如集群外部） | forward . 8.8.8.8 |
| kubernetes | 从 Kubernetes API Server 读取 Service/Pod DNS 记录 | kubernetes cluster.local |
| loop | 检测 DNS 解析环路，自动退出 | loop |
| reload | 自动重载 Corefile 配置 | reload |
巡检要点： 检查 Corefile 中插件顺序是否合理。
cache 应放在 kubernetes 或 forward 之前，否则缓存失效；loop 插件必须启用，防止配置错误导致集群 DNS 风暴。
2.2 缓存机制与失效策略
CoreDNS 的 cache 插件使用 LRU（最近最少使用） 淘汰算法，支持正缓存（成功响应）和负缓存（NXDOMAIN 等错误响应）。
- 正缓存 TTL： 默认 30 秒，可通过
cache [TTL]调整。 - 负缓存 TTL： 默认 5 秒，防止频繁查询不存在的记录。
- 容量限制： 默认 10000 条记录，超过后淘汰最久未使用的条目。
- Prefetch（预取）： 当缓存条目在 TTL 剩余 10% 时被访问，自动异步刷新，减少尾部延迟。
异常场景： 如果
cache 插件配置了过大的 TTL（如 600 秒），当 Service 后端 Pod 发生滚动更新时，客户端可能长时间解析到已删除的 Pod IP，导致连接失败。巡检时应关注缓存命中率与 TTL 设置的匹配度。
2.3 与 etcd / API Server 的交互关系
CoreDNS 通过 kubernetes 插件与 API Server 交互，不直接读写 etcd。交互流程如下：
- Watch 机制： CoreDNS 启动时向 API Server 发起
Watch请求，监听 Service、EndpointSlice、Pod 等资源的变化。 - 本地缓存： 将 Watch 到的资源数据存储在内存中，构建 DNS 记录映射表。
- 查询响应： 收到 DNS 查询时，直接从本地内存映射表查找，无需实时请求 API Server。
- 增量更新： 当资源发生变化（如 Service 删除、Pod 就绪状态变更），API Server 推送 Event，CoreDNS 增量更新本地缓存。
根因定位线索： 如果 CoreDNS 日志中出现
kubernetes: endpoint update took too long 或 watch channel closed，说明 CoreDNS 与 API Server 之间的 Watch 连接不稳定，可能导致 DNS 记录更新延迟或丢失。此时应检查 API Server 负载、etcd 读写延迟以及 CoreDNS 的 --kubeconfig 连接参数。
2.4 典型巡检指标速查
| 指标名称（Prometheus） | 含义 | 异常阈值参考 |
|---|---|---|
coredns_dns_requests_total |
DNS 请求总数（按 type/zone 分类） | 突增 > 3σ 或突降 > 50% |
coredns_dns_request_duration_seconds |
请求延迟分布（P99/P50） | P99 > 1s 或 P50 > 100ms |
coredns_cache_hits_total |
缓存命中次数 | 命中率 < 80% 需关注 |
coredns_cache_misses_total |
缓存未命中次数 | 突增可能表示缓存抖动 |
coredns_kubernetes_dns_programming_duration_seconds |
DNS 记录更新延迟（从 API Server 事件到本地缓存生效） | P99 > 5s 表示 Watch 处理瓶颈 |
巡检脚本建议： 在巡检脚本中同时采集 CoreDNS Pod 日志中的
watch channel closed 出现频率，以及 coredns_kubernetes_dns_programming_duration_seconds 指标。如果两者同时异常，大概率是 API Server 或 etcd 性能瓶颈导致 Watch 连接不稳定，而非 CoreDNS 自身问题。