2. 故障域基础理论：故障域定义、物理故障域与逻辑故障域
故障域（Fault Domain）是集群可靠性工程中最基础的概念之一。它定义了一组共享同一故障风险边界的资源集合——当该边界内的某个关键组件（电源、网络设备、制冷系统或软件服务）失效时，集合内的所有资源都会同时受到影响。理解故障域的层次与边界，是设计高可用集群、规划升级策略以及编写Backstage验证插件的前提。
2.1 故障域的核心定义
故障域的本质是“单点故障的扩散半径”。一个故障域内的任意资源失效，不会影响其他故障域内的资源。在集群升级场景中，故障域边界决定了升级操作的安全并发粒度：
- 共享风险组（Shared Risk Group, SRG）：同一故障域内的节点属于同一个SRG，一次故障可能同时导致该组内所有节点不可用。
- 故障隔离边界：不同故障域之间应具备物理或逻辑上的隔离，确保一个域的故障不会级联扩散到相邻域。
- 升级窗口：升级操作必须逐故障域进行，且必须等待前一个域的健康检查通过后，才能进入下一个域。
关键原则：故障域是集群升级的“原子操作单元”。一次升级操作只能影响一个故障域内的节点，且该域内的所有节点必须同时完成升级与验证。
2.2 物理故障域
物理故障域基于数据中心基础设施的物理拓扑划分，通常包含三个层次：机架、电源域和网络域。下表总结了各层次的定义、故障范围及典型隔离措施：
| 物理故障域 | 定义 | 故障范围 | 典型隔离措施 |
|---|---|---|---|
| 机架（Rack） | 同一机柜内的所有服务器 | 机架顶部交换机故障、机架内供电中断、机架级散热失效 | 跨机架部署主备节点；机架间使用独立PDU |
| 电源域（Power Domain） | 由同一配电单元（PDU）或UPS供电的一组设备 | PDU跳闸、UPS电池耗尽、市电输入中断 | 双路供电（A/B路）；每个节点连接两个独立PDU |
| 网络域（Network Domain） | 共享同一网络叶子交换机或ToR的设备 | 叶子交换机宕机、光纤链路中断、广播风暴 | Spine-Leaf架构；多路径ECMP；BGP多跳 |
在物理故障域的设计中，最常被忽视的是电源域与网络域的重叠边界。例如，同一机架内的服务器可能同时连接到同一个PDU和同一个ToR交换机，此时机架本身就是一个复合故障域。升级计划必须识别这种重叠关系，避免将多个物理域视为独立边界。
实践建议：在Backstage插件中，物理故障域信息应通过CMDB或基础设施API自动获取，并标记在每个节点的标签（Label）中。例如：
topology.kubernetes.io/zone、failure-domain.beta.kubernetes.io/rack。
2.3 逻辑故障域
逻辑故障域是基于软件抽象或云平台API定义的故障边界，不直接对应物理设备，但通常映射到底层物理拓扑。最常见的逻辑故障域是可用区（Availability Zone, AZ）和区域（Region）。
2.3.1 可用区（AZ）
AZ是云提供商或数据中心内一个独立的故障隔离单元，通常包含一个或多个数据中心建筑，拥有独立的电力、网络和制冷系统。AZ的特征包括：
- 低延迟互联：同一Region内的AZ之间通过高带宽、低延迟光纤连接，延迟通常在1-2ms以内。
- 独立故障边界：一个AZ的故障（如电力中断、火灾、洪水）不会影响其他AZ。
- 跨AZ复制：有状态服务（数据库、缓存）必须跨AZ部署以实现高可用。
2.3.2 区域（Region）
Region是地理上隔离的完整云服务区域，包含多个AZ。Region之间通过公网或专线互联，延迟较高（通常10-100ms）。Region的设计目标包括：
- 地理容灾：Region级故障（如大规模地震、政治事件）不影响其他Region。
- 数据主权：数据必须存储在特定Region内以满足合规要求。
- 全局负载均衡：用户流量通过DNS或全局负载均衡器路由到最近的Region。
| 逻辑故障域 | 隔离粒度 | 典型故障场景 | 升级策略 |
|---|---|---|---|
| 可用区（AZ） | 数据中心建筑级 | 单栋建筑电力中断、AZ级网络分区 | 逐AZ滚动升级，每个AZ升级完成后验证跨AZ流量 |
| 区域（Region） | 地理区域级 | 大规模自然灾害、Region级云服务中断 | 跨Region蓝绿部署，DNS流量切换 |
常见误区：不要将AZ等同于物理机架。一个AZ可能包含多个机架、多个电源域和多个网络域。在升级计划中，AZ是逻辑边界，但物理故障域是实际风险边界。Backstage插件必须同时验证逻辑边界和物理边界的一致性。
2.4 故障域在集群升级中的关键作用
在集群升级过程中，故障域边界决定了以下三个核心参数：
- 并发升级节点数：同一故障域内的节点可以同时升级，但不同故障域之间必须串行或有限并发。
- 健康检查范围：每个故障域升级完成后，必须验证该域内所有节点的健康状态，以及跨域通信是否正常。
- 回滚边界：如果某个故障域升级失败，回滚操作应仅限于该域，不影响其他已升级或未升级的域。
Backstage插件验证点：在编写升级验证插件时，必须从集群元数据中提取故障域拓扑，并检查：
1. 每个节点是否被正确分配了故障域标签（如
2. 同一故障域内的节点版本是否一致。
3. 跨故障域的节点版本差异是否在允许范围内（通常不超过1个版本）。
1. 每个节点是否被正确分配了故障域标签（如
failure-domain.beta.kubernetes.io/zone）。2. 同一故障域内的节点版本是否一致。
3. 跨故障域的节点版本差异是否在允许范围内（通常不超过1个版本）。
2.5 故障域设计原则总结
| 原则 | 说明 | 违反后果 |
|---|---|---|
| 最小化共享风险 | 关键服务的主备实例必须部署在不同故障域 | 单故障域失效导致服务完全不可用 |
| 故障域层次化 | 物理域与逻辑域需分层定义，避免扁平化 | 升级计划无法精确控制风险边界 |
| 自动化验证 | 故障域信息应通过API自动获取，避免人工维护 | 配置漂移导致升级验证失效 |
| 升级顺序确定性 | 每次升级必须按照固定的故障域顺序执行 | 并发升级导致跨域故障扩散 |