2. 核心概念：故障域（Fault Domain）的定义、类型与隔离基本原则
2.1 故障域的定义
故障域（Fault Domain）是平台工程中描述“当某个组件失效时，受影响的资源集合边界”的核心概念。在 Kubernetes 集群与 IDP 环境中，故障域定义了故障传播的物理或逻辑范围——同一故障域内的资源共享相同的失效风险，而跨故障域的资源则具备独立失效的能力。
关键理解：故障域不是“故障发生的位置”，而是“故障影响的边界”。设计 IDP 时，必须确保关键工作负载的副本分布在不同的故障域中，从而将单点失效的爆炸半径控制在最小范围。
2.2 故障域的类型
在平台工程与 Kubernetes 集群升级场景中，故障域通常分为以下三类：
| 类型 | 定义 | Kubernetes 中的典型表现 | 升级影响示例 |
|---|---|---|---|
| 物理故障域 | 基于硬件、电源、网络、机架等物理基础设施划分的边界 | 节点（Node）、机架（Rack）、数据中心（DC） | 整机架断电导致该机架上所有 Pod 同时不可用 |
| 逻辑故障域 | 基于软件配置、服务依赖、网络分区等逻辑维度划分的边界 | 命名空间（Namespace）、Deployment、Service Mesh 分区 | 控制面组件升级导致某命名空间内所有 Pod 调度失败 |
| 可用区（AZ）故障域 | 云提供商定义的独立可用区，每个 AZ 拥有独立的电力、冷却和网络 | topology.kubernetes.io/zone 标签 | 某 AZ 网络故障，该 AZ 内所有节点标记为 NotReady |
实践提示：在集群升级演练中，物理故障域和可用区故障域通常由基础设施层保证隔离；逻辑故障域则需要平台工程团队通过 Pod 反亲和、PodDisruptionBudget、拓扑分布约束等 Kubernetes 原生机制主动构建。
2.3 故障域隔离的基本原则
故障域隔离是 IDP 高可用设计的基石。以下四项基本原则指导着集群升级故障域边界测试的每一个环节：
- 最小共享原则——关键工作负载的多个副本不应共享同一个故障域。例如，3 副本的 Web 服务应分布在 3 个不同的可用区或 3 个不同的物理节点上。
- 爆炸半径控制原则——任何单一故障域失效时，受影响的副本数不得超过总副本数的 50%（对于有状态服务）或 1/N（对于无状态服务，N 为副本总数）。
- 升级顺序隔离原则——集群升级操作必须按故障域分批执行，确保同一时间只有一个故障域处于升级状态，其余故障域保持正常服务。
- 可观测性覆盖原则——每个故障域的边界必须被监控、告警和日志系统完整覆盖，以便在升级过程中快速定位故障域边界是否被突破。
2.4 故障域隔离的拓扑结构
下图展示了在 3 可用区集群中，一个 6 副本 Deployment 的故障域隔离设计。每个可用区承载 2 个 Pod 副本，且通过 Pod 反亲和规则确保同一可用区内不会调度超过 2 个副本。
2.5 故障域边界测试的核心关注点
在集群升级故障域边界测试中，需要重点验证以下隔离能力是否生效：
- PodDisruptionBudget（PDB）——验证 PDB 配置是否能在升级驱逐时阻止超过 minAvailable 阈值的 Pod 同时不可用。
- 拓扑分布约束——验证 Pod 是否按照 topologyKey 均匀分布在各个故障域中，是否存在“扎堆”现象。
- 节点升级顺序——验证升级工具（如 kured、cluster-api）是否严格按故障域分批执行节点排空和升级。
- 跨故障域流量——验证 Service 和 Ingress 是否能在某个故障域升级期间将流量正确路由到其他可用区的健康 Pod。
常见陷阱：许多团队仅关注物理节点级别的故障域隔离，却忽略了逻辑故障域（如控制面组件、etcd 成员、Ingress Controller 实例）的隔离。在集群升级过程中，控制面组件的故障域边界一旦被突破，可能导致整个集群不可用，即使工作负载节点仍然健康。
2.6 故障域隔离的 Kubernetes 原生实现
下表总结了在 Kubernetes 中实现故障域隔离的核心资源及其作用：
| Kubernetes 资源 | 故障域类型 | 配置示例 | 升级场景作用 |
|---|---|---|---|
| Pod 反亲和（PodAntiAffinity） | 物理 / 可用区 | topologyKey: kubernetes.io/hostname |
确保同一节点不调度两个相同副本 |
| 拓扑分布约束（TopologySpreadConstraints） | 可用区 / 逻辑 | topologyKey: topology.kubernetes.io/zone |
确保副本在各可用区间均匀分布 |
| PodDisruptionBudget | 逻辑 | minAvailable: 2 |
限制升级期间同时中断的 Pod 数量 |
| 节点亲和（NodeAffinity） | 物理 / 可用区 | requiredDuringSchedulingIgnoredDuringExecution |
将关键 Pod 固定到特定故障域 |
| 多可用区 Service | 可用区 | 跨可用区 EndpointSlice | 故障域失效时自动路由到其他可用区 |
演练设计提示：在后续章节的故障域边界测试中，我们将通过模拟单个可用区完全失效、控制面组件升级、节点排空等场景，逐一验证上述隔离机制是否按预期工作。建议在演练前使用
kubectl describe pod 和 kubectl get pod -o wide 确认当前副本的故障域分布状态。