1. 故障域隔离基础概念
1.1 什么是故障域
故障域（Failure Domain） 是指系统中一组共享同一故障风险组件的资源集合。当该组件发生故障时，集合内的所有资源都会受到影响。在分布式系统和 Kubernetes 中，故障域是设计高可用架构的核心抽象单元。
故障域的本质是故障隔离边界——将系统划分为多个独立失效区域，确保一个区域的故障不会级联扩散到其他区域。故障域越小，系统可用性越高，但管理成本也相应增加。
核心原则： 永远不要将应用的所有副本部署在同一个故障域内。这是分布式系统高可用的第一性原理。
1.2 故障域的类型与层级
Kubernetes 集群中常见的故障域分为三个层级，从底层基础设施到上层节点，形成树状结构：
| 故障域类型 | 层级 | 故障范围 | Kubernetes 标签示例 | 典型故障场景 |
|---|---|---|---|---|
| 节点（Node） | 物理机/虚拟机 | 单台机器 | kubernetes.io/hostname |
硬件故障、OS 崩溃、内核 Panic |
| 可用区（Zone） | 数据中心内独立设施 | 独立供电/网络/制冷单元 | topology.kubernetes.io/zone |
机架断电、交换机故障、空调失效 |
| 区域（Region） | 地理区域 | 整个数据中心集群 | topology.kubernetes.io/region |
自然灾害、大规模电力中断、光缆被挖断 |
实践建议： 生产环境至少应使用 可用区（Zone） 级别的故障域隔离。仅使用节点级别隔离无法应对数据中心级别的故障。
1.3 故障域隔离的层次结构
下图展示了 Kubernetes 集群中故障域的层次关系，以及 Pod 副本如何跨故障域分布：
1.4 为什么 Kubernetes 需要故障域隔离
在 Kubernetes 中，故障域隔离不是可选项，而是生产级部署的强制性要求。以下是四个核心原因：
- 消除单点故障（SPOF）
默认情况下，Kubernetes 调度器可能将 Pod 副本调度到同一节点或同一可用区。一旦该故障域失效，所有副本同时不可用，导致服务完全中断。 - 满足 SLA 承诺
企业级应用通常要求 99.99% 以上可用性。跨故障域部署是达成 SLA 的基础条件，也是云平台（AWS/Azure/GCP）服务等级协议的前提。 - 实现滚动更新与灰度发布
跨故障域分布 Pod 后，滚动更新可以逐个故障域推进，即使某个域更新失败，其他域仍可正常服务，实现零停机发布。 - 应对级联故障
现代分布式系统中，一个组件的故障可能引发资源耗尽、流量雪崩等连锁反应。故障域隔离提供了物理层面的故障熔断机制。
常见误区： 很多团队认为只要设置
replicas=3 就实现了高可用。实际上，如果 3 个副本都在同一个节点或同一个可用区，这仍然是单点故障架构。故障域隔离必须通过 Pod 反亲和性（PodAntiAffinity） 和 拓扑分布约束（TopologySpreadConstraints） 来显式声明。
1.5 故障域隔离的收益对比
以下表格对比了是否实施故障域隔离的差异：
| 对比维度 | 未实施故障域隔离 | 实施故障域隔离 |
|---|---|---|
| 单节点故障影响 | 可能丢失所有副本 | 仅丢失 1/N 副本 |
| 可用区故障影响 | 服务完全中断 | 服务降级但可用 |
| 滚动更新风险 | 更新失败导致全量回滚 | 逐个域更新，失败可回滚单个域 |
| 资源利用率 | 可能集中使用，利用率高 | 分散部署，略有资源碎片 |
| 运维复杂度 | 低，无需额外配置 | 中等，需配置亲和性规则 |
| 理论可用性（3副本） | 99.9%（单域） | 99.999%（跨3域） |
1.6 故障域隔离的两种实现模式
Kubernetes 提供了两种原生机制来实现故障域隔离，后续章节将深入讲解：
模式一：Pod 反亲和性（PodAntiAffinity）
声明式地要求 Pod 不要与同类 Pod 调度到同一故障域。
模式二：拓扑分布约束（TopologySpreadConstraints）
声明式地要求 Pod 在故障域之间均匀分布，支持最大倾斜度控制。
声明式地要求 Pod 不要与同类 Pod 调度到同一故障域。
模式二：拓扑分布约束（TopologySpreadConstraints）
声明式地要求 Pod 在故障域之间均匀分布，支持最大倾斜度控制。
两种模式各有适用场景，在 Helm Values 管理中，我们可以通过参数化配置灵活切换，实现精细化故障域隔离策略。这正是本课程的核心实战内容。