故障域隔离原理：故障域定义、故障域与可用区的关系、隔离边界设计原则
故障域隔离是多租户平台实现高可用与安全隔离的核心机制。本章从故障域的基本定义出发，厘清其与可用区（Availability Zone, AZ）的关系，并给出隔离边界的设计原则，为后续章节的故障切换与用户隔离策略奠定理论基础。
2.1 故障域定义
故障域（Fault Domain, FD） 是指一组共享单一故障点的物理或逻辑资源集合。当该故障点失效时，集合内的所有资源将同时受到影响。故障域的核心目的是通过将不同租户或工作负载分散到独立的故障域中，限制爆炸半径。
| 故障域层级 | 典型故障点 | 影响范围 | 隔离粒度 |
|---|---|---|---|
| 物理机/节点 | 电源、网卡、磁盘 | 单台服务器 | 最细 |
| 机架/机柜 | ToR交换机、PDU | 整机架服务器 | 中等 |
| 可用区（AZ） | 数据中心电力、制冷 | 整个数据中心 | 较粗 |
| 区域（Region） | 自然灾害、骨干网中断 | 地理区域 | 最粗 |
关键认知：故障域是“共命运”的集合。在设计多租户平台时，必须确保两个关键租户或两个控制平面副本不在同一个故障域内，否则一次故障将导致双倍损失。
2.2 故障域与可用区的关系
可用区（AZ）是云平台中最常见的故障域抽象。一个可用区通常对应一个独立的数据中心或数据中心内的独立供电/网络区域。故障域与可用区的关系可以概括为：可用区是故障域的一种具体实现，但故障域的概念比可用区更广泛。
- 包含关系：一个可用区内部可以包含多个更细粒度的故障域（如机架、节点）。
- 隔离级别：可用区之间通常具有物理隔离（独立电力、独立网络），而可用区内部的故障域共享可用区级别的资源。
- 设计目标：故障域设计关注“什么会一起坏”，可用区设计关注“如何分布工作负载以容忍AZ级故障”。
实践要点：在Kubernetes集群中，
topology.kubernetes.io/zone 标签标识节点所属的可用区，而 topology.kubernetes.io/region 标识区域。Pod反亲和性策略可以基于这些拓扑键实现故障域感知调度。
2.3 隔离边界设计原则
在多租户平台门户中，隔离边界的设计直接决定了故障的爆炸半径和租户的SLA保障。以下是经过生产验证的五大设计原则：
- 最小共享原则：每个故障域内的共享资源种类越少，隔离效果越好。控制平面组件（API Server、Scheduler）与数据平面组件（Pod、Volume）应分属不同的故障域。
- 反亲和部署原则：同一租户的关键工作负载、同一微服务的多个副本必须分布在至少2个故障域中。Kubernetes的
podAntiAffinity和topologySpreadConstraints是实现此原则的常用手段。 - 故障域感知调度原则：调度器必须感知故障域拓扑，避免将高可用工作负载集中到同一个机架或可用区。调度策略应支持硬约束（required）和软约束（preferred）两种模式。
- 爆炸半径限制原则：任何单一故障域失效不应影响超过50%的租户或超过50%的控制平面容量。通常建议将关键组件分布在3个或更多故障域中。
- 可观测性原则：每个故障域必须具有独立的监控指标、日志和告警通道，以便在故障发生时快速定位受影响的故障域范围。
常见误区：不要将“高可用”等同于“多副本”。如果所有副本都在同一个机架或同一个可用区内，那么一次机架断电或AZ故障将导致所有副本同时失效。真正的故障域隔离要求副本分布在不同的故障域中。
2.4 隔离边界设计清单
在实际设计平台门户的故障域隔离方案时，建议对照以下清单进行逐项检查：
| 检查项 | 描述 | 验收标准 |
|---|---|---|
| 控制平面隔离 | API Server、etcd、Scheduler等组件分布在至少3个故障域 | 任意1个故障域失效，控制平面仍可正常服务 |
| 租户数据隔离 | 不同租户的持久卷、数据库实例位于不同故障域 | 故障域失效仅影响该域内的租户 |
| 网络隔离 | 租户网络流量不跨故障域转发（除非显式配置） | 故障域内网络故障不扩散到其他域 |
| 监控与告警 | 每个故障域有独立的监控采集点和告警规则 | 故障发生时5分钟内定位到具体故障域 |
| 故障切换测试 | 定期模拟故障域失效，验证自动切换流程 | 切换时间符合SLA（通常<30秒） |
设计建议：在平台门户的租户创建流程中，应自动为每个租户分配至少2个故障域，并将租户的初始工作负载均匀分布。对于高SLA租户（如金融、医疗），建议强制使用3个故障域。