1. 课程导论：DNS在Kubernetes中的核心作用、故障域概念、Helm部署与DNS的关联性
1.1 DNS在Kubernetes中的核心作用
在Kubernetes集群中，DNS（域名系统）是服务发现与通信的基础设施层。没有DNS，Pod之间只能通过硬编码的ClusterIP或环境变量进行通信，这在动态调度的环境中几乎不可维护。
Kubernetes内置的CoreDNS（或kube-dns）为集群提供以下关键能力：
- 服务域名解析：每个Service自动获得一个
<service>.<namespace>.svc.cluster.local格式的DNS记录。 - Pod域名解析：通过Headless Service或StatefulSet，Pod可获得
<pod-name>.<service>.<namespace>.svc.cluster.local记录。 - 集群外部域名转发：将集群外域名（如
api.example.com）转发到上游DNS服务器。 - SRV记录与负载均衡：支持端口发现和基于DNS的轮询负载均衡。
关键指标：在生产集群中，DNS查询失败会导致70%以上的服务间调用异常，而DNS延迟超过100ms会显著增加P99响应时间。
1.2 故障域概念
故障域（Failure Domain）是指系统中共享单一故障点的一组组件。当该故障点失效时，域内所有组件都会受到影响。在Kubernetes架构中，常见的故障域层级包括：
| 故障域层级 | 示例 | 影响范围 |
|---|---|---|
| 节点级 | 单台Worker节点宕机 | 该节点上的所有Pod |
| 机架级 | 交换机/电源故障 | 同一机架内的所有节点 |
| 可用区级 | AZ（Availability Zone）网络中断 | 该AZ内的所有集群资源 |
| 集群级 | CoreDNS Pod全部不可用 | 整个集群的服务发现 |
本课程聚焦于DNS故障域——即CoreDNS组件及其依赖链路（如kubelet、kube-proxy、网络插件）构成的故障边界。当DNS故障域被击穿时，集群内部所有依赖域名解析的通信都会中断。
常见误区：很多团队只关注应用层的Pod副本数，却忽略了DNS基础设施的单点风险。例如，CoreDNS只部署2个副本且放在同一可用区，一旦该可用区网络故障，整个集群的服务发现将瘫痪。
1.3 Helm部署与DNS的关联性
Helm作为Kubernetes的包管理工具，在部署应用时与DNS存在三层关联：
- Chart内部依赖：Helm Chart中定义的Service、Ingress、StatefulSet等资源，其域名解析依赖于集群DNS的可用性。
- 部署流程依赖：Helm的
helm install/upgrade操作中，如果Chart包含post-install或pre-upgrade钩子（Hook），这些钩子通常需要调用Kubernetes API或访问其他Service，这同样依赖DNS解析。 - 故障域传播：当DNS故障发生时，Helm部署操作会失败或超时，导致发布中断、回滚困难，甚至造成部署状态不一致（部分资源已创建，部分未完成）。
下图展示了Helm部署过程中DNS故障域的传播路径：
1.4 课程核心目标
通过本课程，你将掌握以下能力：
| 能力维度 | 具体内容 | 对应章节 |
|---|---|---|
| 诊断 | 识别DNS故障域中的薄弱环节 | 第2-5章 |
| 设计 | 在Helm Chart中实现DNS故障域隔离 | 第6-15章 |
| 部署 | 配置Helm Values以适配不同DNS故障场景 | 第16-22章 |
| 验证 | 编写故障注入测试与监控告警规则 | 第23-28章 |
| 实战 | 完整案例：多AZ部署的DNS故障域划分 | 第29-30章 |
学习建议：如果你对CoreDNS的内部工作原理还不熟悉，建议先阅读第2章“CoreDNS架构与故障模式分析”，再回到本章理解整体框架。