4. 故障域理论：物理故障域与软件故障域
故障域（Fault Domain）是集群中一旦发生故障，会同时影响一组组件或租户的物理或逻辑边界。在 Kubernetes 多租户集群中，故障域的划分直接决定了租户可用性承诺和隔离策略的有效性。本章从物理故障域和软件故障域两个维度展开，并分析其对租户的影响范围。
4.1 物理故障域
物理故障域由基础设施的物理拓扑决定，常见层级包括机架、可用区（Availability Zone, AZ）和数据中心。故障在物理域内具有传播性：同一机架内的节点共享电源和网络交换机，同一可用区内的机架共享数据中心基础设施。
| 物理故障域层级 | 故障范围 | 典型故障场景 | Kubernetes 对应资源 |
|---|---|---|---|
| 机架（Rack） | 同一机架内所有节点 | 电源模块故障、ToR 交换机宕机 | topology.kubernetes.io/zone 标签（机架级） |
| 可用区（AZ） | 同一可用区内所有机架 | 区域电力中断、骨干网络故障 | topology.kubernetes.io/region 标签 |
| 数据中心（DC） | 整个数据中心 | 自然灾害、大规模光缆中断 | 跨集群联邦或备份集群 |
关键原则： 物理故障域是不可跨越的——同一机架内的两台服务器无法避免机架级电源故障。多租户集群必须将租户工作负载分散到至少两个物理故障域，才能实现基础的高可用。
4.2 软件故障域
软件故障域由集群控制面的组件拓扑决定，主要包括 etcd 成员和 API Server 实例。软件故障域与物理故障域存在映射关系，但故障传播机制不同：软件故障可能由配置错误、版本兼容性、资源耗尽等因素触发，不一定伴随物理硬件故障。
4.2.1 etcd 成员故障域
etcd 集群采用 Raft 共识算法，成员数量通常为 3 或 5。每个 etcd 成员是一个独立的故障域：
- 成员宕机： 单成员故障不影响集群写入（多数派存活），但会降低容错能力。
- 成员网络分区： 少数派成员与多数派隔离时，该成员上的租户读请求可能返回过期数据（Stale Read）。
- 成员数据损坏： 磁盘故障或 etcd 数据目录损坏导致成员无法启动，需从快照恢复。
4.2.2 API Server 故障域
API Server 是无状态组件，通常以 Deployment 方式运行多个副本。每个 API Server 实例是一个独立的软件故障域：
- 实例崩溃： 负载均衡器自动剔除故障实例，客户端重试后恢复。
- 实例过载： 单个实例因租户突发请求导致 OOM 或 goroutine 泄漏，影响该实例上的所有租户。
- 版本不匹配： 滚动升级期间，新旧版本 API Server 共存，可能导致部分 API 资源版本不可用。
实践建议： 将 etcd 成员和 API Server 实例部署在不同的物理故障域（至少跨 3 个可用区），使软件故障域与物理故障域正交，避免单点物理故障导致整个控制面不可用。
4.3 故障域对租户的影响范围
故障域对租户的影响取决于租户工作负载的分布策略和控制面的隔离机制。以下表格总结了不同故障域类型对租户的影响范围：
| 故障域类型 | 故障示例 | 影响范围 | 租户感知 |
|---|---|---|---|
| 单机架电源故障 | 机架 PDU 跳闸 | 该机架上所有 Pod（可能跨多个租户） | Pod 重建延迟，节点不可用 |
| 可用区网络中断 | AZ 间带宽降级 | 该 AZ 内所有节点和 Pod | 跨 AZ 流量延迟增加，Pod 调度受限 |
| etcd 成员宕机 | etcd 进程 OOM | 控制面写入延迟增加（多数派仍存活） | API 响应变慢，但数据不丢失 |
| etcd 多数派故障 | 两个 etcd 成员同时宕机（3 成员集群） | 整个集群控制面不可用 | 所有租户无法创建/更新/删除资源 |
| API Server 实例故障 | 单个 API Server 崩溃 | 该实例上的活跃连接中断 | 客户端重连后恢复，影响极小 |
| API Server 版本不兼容 | 升级后旧版 API 被移除 | 使用已移除 API 版本的租户 | 特定租户的 CI/CD 流水线失败 |
重要： 租户隔离不能消除故障域的影响，只能缩小影响范围。例如，将租户 A 的所有 Pod 调度到同一可用区，当该可用区故障时，租户 A 完全不可用；而将租户 A 的 Pod 分散到三个可用区，则单个可用区故障仅影响 1/3 的 Pod。故障域设计的目标是控制爆炸半径，而非完全避免故障。
4.4 故障域拓扑图
下图展示了物理故障域与软件故障域的层级关系，以及故障传播路径：
4.5 故障域设计原则
- 最小故障域原则： 每个租户的工作负载应至少分布在 2 个物理故障域（机架或可用区），避免单点故障导致租户完全不可用。
- 控制面故障域正交： etcd 成员和 API Server 实例应跨可用区部署，使控制面故障域与工作负载故障域解耦。
- 租户故障域感知调度： 使用 PodTopologySpreadConstraints 和 PodAntiAffinity 将同一租户的 Pod 打散到不同故障域。
- 故障域容量规划： 每个故障域预留 20%-30% 的冗余容量，确保单故障域失效时其他域能接管流量。
- 故障域可观测性： 监控每个故障域的节点健康、etcd 成员状态、API Server 延迟，并设置故障域级别的告警。
核心结论： 故障域是集群升级和多租户隔离的基础抽象。物理故障域决定了基础设施的可靠性边界，软件故障域决定了控制面的容错能力。租户隔离策略必须显式考虑故障域分布，否则升级或故障事件可能导致租户级服务中断。在后续章节中，我们将基于这些故障域理论，设计具体的 etcd 故障注入测试和租户隔离验证方案。