3. 故障域概念
故障域（Fault Domain）是系统架构中一个基础且关键的概念。它定义了一组共享单一故障点的组件集合——当该故障点失效时，集合内的所有组件都会受到影响。在多租户 Kubernetes 集群中，理解并合理规划故障域是实现租户隔离、保障服务连续性的前提。
故障域通常分为两大类：物理故障域和逻辑故障域。前者与硬件基础设施的物理布局相关，后者则与软件架构的服务边界相关。下面分别展开说明。
3.1 故障域定义
一个故障域由以下三个要素唯一确定：
- 故障边界（Fault Boundary）：故障不会跨越的物理或逻辑边界。例如，一个机架内的电源故障通常不会影响另一个机架。
- 共享风险组（Shared Risk Group, SRG）：位于同一故障域内的组件共享相同的风险。例如，同一可用区内的所有节点共享该可用区的网络和电力风险。
- 影响半径（Blast Radius）：故障发生后，受影响的服务或租户范围。影响半径越小，隔离效果越好。
关键原则：在多租户架构中，应确保任意单一故障域失效时，最多只影响一个租户的 quorum（仲裁）或 SLA（服务等级协议）。这是故障域设计的核心目标。
3.2 物理故障域
物理故障域与数据中心的基础设施直接相关，是故障隔离的第一道防线。常见的物理故障域层级包括：
| 层级 | 定义 | 典型故障场景 | 影响范围 |
|---|---|---|---|
| 机架（Rack） | 共享同一电源分配单元（PDU）和网络交换机的服务器集合。 | PDU 跳闸、交换机端口故障、机架内温度过高。 | 该机架内的所有节点、Pod 和 etcd 实例。 |
| 可用区（Availability Zone, AZ） | 一个或多个数据中心内独立于其他可用区的故障隔离区域，通常拥有独立的电力、冷却和网络。 | 区域级电力中断、骨干网络故障、自然灾害。 | 该 AZ 内的所有节点、持久化存储卷和 etcd 成员。 |
| 区域（Region） | 由多个可用区组成的地理区域，区域间通过高延迟链路互联。 | 大规模地震、区域级政治事件。 | 整个区域内的所有服务。 |
实践建议：对于生产级多租户集群，至少应将 etcd 成员分布在 3 个不同的可用区。这样，即使一个 AZ 完全故障，etcd 集群仍能维持仲裁（quorum），从而保证控制面可用。
3.3 逻辑故障域
逻辑故障域与软件架构的抽象层相关，不直接依赖物理硬件。在多租户 Kubernetes 集群中，逻辑故障域主要体现为服务边界和数据平面边界。
3.3.1 服务故障域
服务故障域以 Kubernetes 控制面组件和 etcd 集群为核心。每个服务组件（如 kube-apiserver、kube-controller-manager、kube-scheduler）以及 etcd 成员，都构成一个逻辑故障域。当某个服务实例崩溃或不可用时，其影响范围受限于该服务的职责边界。
- etcd 集群：作为集群状态存储，etcd 是整个控制面的核心故障域。etcd 的故障会直接影响所有 API 操作和调度决策。
- kube-apiserver：作为控制面入口，apiserver 的故障会导致所有客户端（包括 kubectl、控制器、调度器）无法访问集群。
- kube-controller-manager：负责运行各种控制器（如 Deployment、StatefulSet 控制器），其故障会影响工作负载的自动修复和扩缩容。
- kube-scheduler：负责 Pod 调度，其故障会导致新 Pod 无法被分配到节点。
3.3.2 数据平面故障域
数据平面故障域与租户工作负载直接相关，包括 Pod、Service、持久化存储卷（PV/PVC）以及网络策略。数据平面的故障域设计目标是：一个租户的数据平面故障不应影响其他租户的数据平面。
| 逻辑故障域类型 | 包含组件 | 故障影响范围 | 隔离手段 |
|---|---|---|---|
| 租户命名空间 | Pod、Service、ConfigMap、Secret | 仅该租户的工作负载 | RBAC、NetworkPolicy、ResourceQuota |
| 持久化存储 | PV、PVC、CSI 驱动 | 挂载该存储卷的 Pod | StorageClass、拓扑约束、卷快照 |
| 网络策略域 | Pod 网络、Service 网络、Ingress | 该租户的网络流量 | NetworkPolicy、命名空间隔离、服务网格 |
重要提醒：在集群升级场景中，etcd 故障属于 控制面逻辑故障域 的失效。如果 etcd 集群因升级操作（如成员替换、快照恢复）而失去仲裁，所有租户的控制面操作都将中断。此时，数据平面可能仍在运行，但无法进行任何变更（如滚动更新、扩缩容、故障自愈）。因此，etcd 故障域的设计直接决定了租户恢复的 RTO（恢复时间目标）。
3.4 故障域设计对 etcd 的影响
etcd 作为 Kubernetes 控制面的状态存储，其故障域设计直接决定了集群的可用性。以下是 etcd 故障域设计的关键考量：
- 跨可用区部署：etcd 成员应分布在至少 3 个可用区，避免单可用区故障导致仲裁丢失。
- 机架感知：在同一可用区内，etcd 成员应部署在不同的机架上，避免机架级故障（如 PDU 故障）同时影响多个 etcd 成员。
- 网络隔离：etcd 集群应使用独立的网络路径或 VLAN，避免与其他租户的数据平面流量争抢带宽或受网络攻击影响。
- 存储隔离：etcd 应使用专用的高性能存储（如本地 SSD 或高性能云盘），避免与其他工作负载共享存储资源导致 I/O 争用。
最佳实践：在集群升级演练中，应模拟以下故障域失效场景：
1. 一个可用区内的 etcd 成员完全不可达（网络分区）。
2. 一个机架内的 etcd 成员因电源故障离线。
3. etcd 数据目录所在存储卷损坏（模拟存储故障域失效）。
通过演练验证租户恢复流程是否能在预期 RTO 内完成。
1. 一个可用区内的 etcd 成员完全不可达（网络分区）。
2. 一个机架内的 etcd 成员因电源故障离线。
3. etcd 数据目录所在存储卷损坏（模拟存储故障域失效）。
通过演练验证租户恢复流程是否能在预期 RTO 内完成。