1. 课程导论：灾备缓存巡检的背景与挑战，CoreDNS 在 K8s 集群中的核心作用
1.1 灾备缓存巡检：为什么需要关注“异常样本”？
在大型 Kubernetes 生产集群中，DNS 解析是服务发现与流量调度的基石。一旦 CoreDNS 出现异常，轻则导致服务间调用超时、重试风暴，重则引发大规模服务不可用。灾备缓存巡检的核心目标，是在日常运维中通过日志关联与根因定位，提前发现并修复那些“潜伏”的异常样本，避免其演变为重大故障。
关键认知： 灾备缓存巡检不是简单的“日志收集”，而是面向异常样本的全链路关联分析——从 CoreDNS 日志出发，串联上游 kube-apiserver、下游业务 Pod 以及缓存中间件的状态，最终定位根因。
1.2 CoreDNS 在 K8s 集群中的核心作用
CoreDNS 是 Kubernetes 集群的默认 DNS 组件，承担着服务发现与域名解析的核心职责。其工作流程可概括为：
- Pod 发起 DNS 查询：业务 Pod 通过
cluster.local后缀查询 Service 或 Pod 域名。 - CoreDNS 接收并处理：根据配置的插件链（如
kubernetes、forward、cache）进行解析。 - 缓存命中或回源：若缓存命中则直接返回；否则向上游 DNS 服务器（如集群外部 DNS）发起递归查询。
- 返回结果并记录日志：将解析结果返回给 Pod，同时输出结构化日志（包含查询名、类型、RCODE、耗时等）。
| CoreDNS 核心能力 | 说明 | 灾备巡检关注点 |
|---|---|---|
| 服务发现 | 将 Service 名称解析为 Cluster IP | 解析失败率、超时率 |
| 缓存加速 | 减少对上游 DNS 的重复查询 | 缓存命中率、缓存污染 |
| 健康检查 | 自动剔除故障上游 DNS | 上游健康状态变更频率 |
| 日志审计 | 记录每次查询的详细元数据 | 异常 RCODE 分布、查询延迟 |
1.3 灾备缓存巡检面临的核心挑战
在实际巡检中，我们常遇到以下痛点：
- 日志分散：CoreDNS 日志、kube-apiserver 审计日志、业务 Pod 日志存储在不同系统，难以关联。
- 异常样本淹没：正常查询量巨大，异常样本（如 NXDOMAIN、SERVFAIL、超时）占比极低，容易被忽略。
- 根因模糊：一次 DNS 失败可能是 CoreDNS 自身问题、上游 DNS 故障、网络抖动或缓存污染导致，需要多维度交叉验证。
- 缓存状态不可见：CoreDNS 缓存内部状态（如过期条目、负缓存）缺乏直观监控，异常样本往往在缓存失效后才暴露。
巡检原则： 不要只盯着“错误日志”看。很多灾难性故障的前兆是缓存命中率突然下降或查询延迟缓慢上升——这些“亚健康”样本才是灾备缓存巡检的真正目标。
1.4 CoreDNS 日志关联与根因定位的整体架构
下图展示了灾备缓存巡检中，CoreDNS 日志如何与上下游组件关联，形成根因定位链路：
1.5 本课程的核心学习路径
通过本课程，你将掌握以下关键能力：
| 模块 | 核心内容 | 产出物 |
|---|---|---|
| 日志采集与标准化 | CoreDNS 日志格式解析、结构化采集、缓存状态导出 | 标准化日志 Schema |
| 异常样本识别 | 基于 RCODE、延迟、缓存命中率的异常检测规则 | 异常样本标签体系 |
| 多源日志关联 | CoreDNS 日志 + kube-apiserver 事件 + 上游 DNS 日志关联 | 关联分析流水线 |
| 根因定位算法 | 基于决策树与时间窗口的根因推断 | 根因定位报告 |
| 巡检自动化与告警 | 将巡检流程集成到 SRE 日常运维中 | 巡检 Dashboard |
重要提醒： 灾备缓存巡检不是一次性任务，而是持续演进的闭环。每次根因定位的结果都应反馈到缓存策略、日志采集规则和告警阈值中，形成“巡检-定位-优化”的正向循环。