2. 故障域隔离基础概念
故障域（Fault Domain）是分布式系统与云原生架构中用于界定“单点失效影响范围”的逻辑或物理边界。在 Kubernetes 集群中，正确识别与配置故障域是实现高可用、避免级联故障、保障业务连续性的核心前提。
2.1 故障域的定义与重要性
| 维度 | 说明 |
|---|---|
| 定义 | 一组共享同一失效风险（如电源、网络交换机、物理机架、数据中心）的资源集合。当该集合内任一组件失效时，集合内所有资源均可能受影响。 |
| 隔离目标 | 确保工作负载的多个副本分布在不同的故障域中，使单一故障域失效时，仍有副本保持可用，从而满足 SLO（服务等级目标）。 |
| 重要性 | 防止单点故障扩散为全局中断；降低爆炸半径；满足合规与容灾要求；为平台门户的“一键演练”提供可量化的失效边界。 |
核心原则： 故障域隔离不是“避免故障”，而是“控制故障影响范围”。在平台门户演练编排中，每个故障注入动作必须明确其目标故障域，否则演练可能意外中断整个集群。
2.2 Kubernetes 中的常见故障域表现形式
Kubernetes 原生通过 节点标签（Labels） 与 拓扑分布约束（Topology Spread Constraints） 来定义和利用故障域。以下为最常见的故障域层级：
- 物理/虚拟层级： 机架（Rack）、可用区（Zone）、地域（Region）。
- Kubernetes 原生层级：
kubernetes.io/hostname（节点级）、topology.kubernetes.io/zone（可用区级）、topology.kubernetes.io/region（地域级）。 - 自定义层级： 平台门户可定义
fault-domain.platform.io/rack、fault-domain.platform.io/pdu等标签，用于模拟更细粒度的故障场景。
演练设计提示： 在 Helm Chart 的 values.yaml 中，建议将
topologySpreadConstraints 作为可配置参数暴露，以便平台门户在演练时动态调整分布策略，验证不同故障域配置下的容灾效果。
2.3 故障域隔离的典型架构
下图展示了一个跨可用区部署的 Kubernetes 集群中，故障域如何通过节点标签与 Pod 分布约束实现隔离：
2.4 故障域与 Helm 演练编排的映射
在平台门户集成 Helm 的故障域演练中，需要将上述概念映射为可执行的编排参数：
| 故障域层级 | Kubernetes 标签示例 | Helm values 配置示例 | 演练注入动作 |
|---|---|---|---|
| 节点级 | kubernetes.io/hostname: node-1 |
faultDomain.node: "node-1" |
停止 kubelet / 网络隔离 |
| 机架级 | topology.kubernetes.io/rack: rack-01 |
faultDomain.rack: "rack-01" |
模拟 PDU 断电 |
| 可用区级 | topology.kubernetes.io/zone: us-east-1a |
faultDomain.zone: "us-east-1a" |
模拟 AZ 不可达 |
| 地域级 | topology.kubernetes.io/region: us-east-1 |
faultDomain.region: "us-east-1" |
模拟跨地域网络中断 |
演练编排注意： 故障域标签必须与实际基础设施拓扑一致。如果标签配置错误（例如将两个不同机架的节点标记为同一机架），演练将无法真实反映故障隔离效果，甚至可能误导容灾策略的评估。
2.5 故障域隔离的常见误区
- 误区一： 认为 Pod 反亲和（PodAntiAffinity）等同于故障域隔离。实际上，反亲和仅保证 Pod 不调度到同一节点，无法跨可用区或机架分布。
- 误区二： 忽略控制平面组件的故障域分布。etcd、API Server 等组件若集中在同一故障域，集群自身可能先于工作负载失效。
- 误区三： 在演练中只隔离工作负载，不隔离数据平面。例如，仅停止应用 Pod，但未模拟对应 PV 所在存储节点的故障，导致演练结果失真。