1. 课程导论：DNS故障背景、证书轮换与域名解析的关联、课程目标与受众
1.1 故障背景：一次“静默”的集群外部域名解析中断
在Kubernetes生产环境中，集群内的Pod经常需要访问集群外部的服务，例如对象存储、数据库、第三方API或CDN。这些访问通常依赖集群内的CoreDNS（或kube-dns）进行域名解析。当外部域名解析突然失败，而集群内部通信一切正常时，故障定位往往陷入僵局。
本课程源于一个真实案例：某微服务集群在例行TLS证书轮换后，部分Pod无法解析外部域名（如 api.example.com），但集群内部Service名称解析正常。运维团队花费数小时排查网络策略、防火墙规则和CoreDNS配置，最终发现根因隐藏在证书轮换引发的双向TLS认证（mTLS）与DNS-over-TLS（DoT）的交互逻辑中。
关键观察： 证书轮换本身不直接修改DNS记录，但它可能破坏DNS查询链路上的加密握手，导致上游DNS服务器拒绝服务或返回SERVFAIL。
1.2 证书轮换与域名解析的关联：被忽视的依赖链
证书轮换与DNS解析看似属于不同运维领域，但在现代云原生架构中，它们通过以下路径产生强关联：
| 关联层次 | 说明 | 故障风险 |
|---|---|---|
| 传输层安全 | Pod与上游DNS服务器之间使用DoT或DNS-over-HTTPS（DoH） | 证书过期/不匹配导致TLS握手失败，DNS查询被丢弃 |
| mTLS身份验证 | 集群出口代理（如Envoy、Istio sidecar）对DNS查询进行mTLS封装 | 证书轮换后客户端证书不被上游信任，查询被拒绝 |
| 证书吊销列表（CRL） | DNS解析器在验证证书时检查CRL或OCSP响应 | CRL分发延迟导致合法证书被误判为已吊销 |
| 证书存储与热加载 | CoreDNS或sidecar未正确重载新证书 | 旧证书缓存导致持续使用已轮换的凭证 |
下图展示了证书轮换如何影响集群Pod到外部DNS服务器的完整查询路径：
1.3 课程目标
完成本课程后，学员将能够：
- 识别证书轮换引发DNS故障的典型症状（如间歇性SERVFAIL、部分Pod解析失败、日志中TLS错误）。
- 分析从Pod到上游DNS的完整查询链路，定位证书信任链断裂的具体环节。
- 排查CoreDNS、sidecar代理和证书管理组件的配置与日志，使用
tcpdump、openssl s_client和kubectl命令验证TLS握手状态。 - 修复证书轮换后的DNS解析问题，包括证书热加载、mTLS策略更新和DoT端点配置。
- 预防通过监控证书过期时间、自动化轮换流程和灰度发布策略，避免同类故障再次发生。
1.4 课程受众
| 角色 | 所需基础 | 课程价值 |
|---|---|---|
| SRE / 运维工程师 | 熟悉Kubernetes、CoreDNS基本配置 | 掌握证书与DNS交叉故障的系统排查方法 |
| 平台工程师 | 了解服务网格（Istio/Linkerd）和mTLS | 学会设计证书轮换与DNS高可用的协同方案 |
| 安全工程师 | 理解TLS/SSL协议和PKI体系 | 从安全视角优化证书生命周期管理 |
| Kubernetes管理员 | 具备集群网络和DNS排错经验 | 扩展排错知识面，覆盖加密DNS场景 |
学习建议： 本课程包含大量命令行实操和日志分析。建议准备一个测试Kubernetes集群（minikube或kind），并安装cert-manager和CoreDNS，以便跟随课程进行实验验证。
1.5 课程内容概览
课程共分为6个模块，从基础概念到高级排错，层层递进：
- DNS与证书基础 — 回顾Kubernetes DNS解析流程、TLS/证书轮换机制。
- 故障场景复现 — 在测试环境中搭建证书轮换引发DNS失败的完整场景。
- 排查工具与技巧 — 使用
dig、tcpdump、openssl和CoreDNS日志进行深度分析。 - 根因定位实战 — 逐步分析mTLS握手失败、DoT证书不匹配、CRL检查超时等案例。
- 修复与恢复 — 证书热加载、sidecar重启策略、上游DNS端点更新。
- 预防与自动化 — 证书监控、轮换窗口规划、DNS解析健康检查。
下图展示了课程的知识体系结构：
重要提示： 本课程不涉及Kubernetes集群的初始搭建或CoreDNS的安装部署。学员应具备基本的
kubectl操作能力和对DNS协议的理解。如果对Kubernetes DNS基础不熟悉，建议先学习官方文档中关于CoreDNS的章节。