2. 多租户基础模型：租户定义、资源池划分、隔离边界
多租户（Multi-Tenancy）是云原生平台的核心能力，其本质是一套物理或虚拟化基础设施同时服务于多个独立客户（租户），且每个租户感知不到其他租户的存在。在故障域隔离演练中，理解租户的基础模型是设计演练场景、划定爆炸半径、评估风险的前提。
2.1 租户定义与身份模型
租户是资源分配、计费、安全策略和运维管理的最小逻辑单元。不同平台对租户的抽象粒度不同，常见定义方式如下：
| 租户类型 | 典型场景 | 隔离级别 | 故障域关联 |
|---|---|---|---|
| 项目/Project | OpenStack、GCP Project | 网络、存储、计算全隔离 | 每个项目可绑定独立可用区 |
| 命名空间/Namespace | Kubernetes 多租户 | 软隔离（RBAC + NetworkPolicy） | 共享节点池，故障域重叠 |
| 账户/Account | AWS Account、阿里云主账号 | 强隔离（独立 VPC、独立账单） | 每个账户可独立选择 Region/AZ |
| 组织/Organization | 企业级 SaaS 平台 | 逻辑隔离 + 数据隔离 | 按组织划分故障域优先级 |
演练提示： 在故障域隔离演练中，租户定义越粗（如 Account 级），爆炸半径越大，演练前需要更严格的风险评估和回滚预案。建议从 Namespace 级租户开始演练，逐步升级到 Account 级。
2.2 资源池划分策略
资源池划分决定了租户之间的资源竞争关系和故障传播路径。常见的划分模型包括共享池、独享池和混合池三种。
核心原则： 资源池的划分粒度必须与故障域隔离目标对齐。如果两个租户共享同一个物理节点或存储后端，则它们处于同一个故障域内。
2.2.1 计算资源池划分
- 共享节点池： 多个租户的 Pod/VM 混部在同一组物理节点上。资源利用率高，但故障域重叠严重，一个节点故障可能影响多个租户。
- 独占节点池： 每个租户绑定独立的节点组（NodeGroup）。故障域完全隔离，但资源碎片化严重，成本较高。
- 弹性节点池： 基于负载动态调整节点归属，结合了共享和独占的优点，但需要精细的调度策略和故障域感知。
2.2.2 存储资源池划分
| 存储类型 | 共享方式 | 故障域风险 | 演练关注点 |
|---|---|---|---|
| 本地盘（Local SSD） | 节点级独享 | 节点故障 = 数据丢失 | 数据备份与恢复 RTO |
| 分布式存储（Ceph/GlusterFS） | 集群级共享 | OSD 故障影响所有租户 | 存储集群故障域划分 |
| 云盘（EBS/PV） | 租户级独享 | 单盘故障仅影响单租户 | 快照与跨 AZ 迁移 |
| 对象存储（S3/MinIO） | 桶级共享 | 桶策略错误导致数据泄露 | 权限隔离与审计 |
2.2.3 网络资源池划分
网络隔离是多租户故障域隔离中最关键也最容易被忽视的一环。常见的网络隔离模型包括：
- VPC 级隔离： 每个租户拥有独立的虚拟网络，完全隔离 L2/L3 广播域。故障域最大，但网络管理复杂。
- 子网级隔离： 同一 VPC 内通过子网划分租户，结合 ACL 和安全组实现隔离。故障域缩小到子网级别。
- Overlay 网络隔离： 使用 VXLAN/Geneve 封装，租户之间通过隧道隔离。故障域与底层物理网络解耦，但需要 Overlay 控制器的高可用。
- 服务网格隔离： 在 L7 层通过 mTLS 和 RBAC 实现租户间的服务调用隔离。故障域最小，但依赖 Sidecar 代理的稳定性。
常见误区： 很多团队认为网络策略（NetworkPolicy）配置正确就等于网络隔离完成。实际上，NetworkPolicy 只控制 L3/L4 流量，无法防止 ARP 欺骗、DNS 劫持等 L2 攻击。在故障域演练中，必须验证底层网络隔离的有效性，而不仅仅是策略配置。
2.3 隔离边界：计算/存储/网络
隔离边界是故障域隔离的物理或逻辑分界线。以下 SVG 图展示了典型的多租户隔离边界模型：
2.4 隔离边界的故障域映射
隔离边界与故障域之间存在明确的映射关系。以下表格总结了不同隔离边界对应的故障域特征：
| 隔离边界 | 故障域粒度 | 典型故障场景 | 爆炸半径 | 演练验证方法 |
|---|---|---|---|---|
| 计算：独占节点池 | 节点级 | 节点宕机、内核 Panic | 仅影响该租户 | 模拟节点故障，观察租户 Pod 迁移 |
| 计算：共享节点池 | 节点级 | 节点宕机、资源争抢 | 影响所有共享租户 | 注入 CPU 压力，观察其他租户性能衰减 |
| 存储：独立 PV | 卷级 | PV 损坏、存储节点故障 | 仅影响该卷挂载的 Pod | 模拟 PV 读写故障，验证应用降级 |
| 存储：共享存储集群 | 集群级 | OSD 故障、网络分区 | 影响所有使用该集群的租户 | 模拟 OSD 离线，观察存储集群自愈 |
| 网络：独立 VPC | VPC 级 | VPC 网关故障、路由表损坏 | 仅影响该 VPC 内租户 | 模拟 VPC 网关故障，验证跨 VPC 通信 |
| 网络：Overlay 隧道 | 隧道级 | VTEP 故障、隧道封装错误 | 影响该隧道关联的租户 | 模拟 VTEP 节点故障，验证 Overlay 切换 |
2.5 隔离边界的风险控制要点
风险控制黄金法则： 在故障域演练中，隔离边界越靠近共享基础设施层，爆炸半径越大，演练前必须完成以下三项检查：
- 依赖关系梳理： 明确每个租户依赖的共享组件清单（如共享存储集群、共享网络网关）。
- 熔断机制验证： 确认共享组件是否具备熔断和限流能力，防止一个租户的故障扩散到其他租户。
- 回滚预案： 针对共享组件的故障演练，必须准备快速回滚脚本，确保在 5 分钟内恢复服务。
以下 SVG 图展示了隔离边界与故障域之间的映射关系，以及风险控制的关键检查点：
2.6 租户基础模型的最佳实践
基于以上分析，在多租户故障域隔离演练中，建议遵循以下最佳实践：
- 租户定义标准化： 统一使用
tenant_id作为资源标签，确保所有资源（计算、存储、网络）都能通过标签关联到具体租户。 - 资源池分层划分： 按照 Gold/Silver/Bronze 三级 SLA 划分资源池，Gold 租户使用独占节点池 + 独立存储卷 + 独立 VPC，Bronze 租户使用共享池。
- 隔离边界文档化： 每个租户的隔离边界必须形成文档，包括计算节点列表、存储卷列表、网络策略列表，并在演练前进行审计。
- 故障域感知调度： 使用拓扑分布约束（Topology Spread Constraints）和 Pod 反亲和性，确保同一租户的 Pod 分布在不同的故障域中。
- 演练前基线采集： 在演练前采集每个租户的基线指标（CPU 使用率、网络延迟、存储 IOPS），用于演练后的对比分析。
演练案例： 某金融云平台在演练中发现，两个租户虽然使用了不同的 VPC，但共享了同一个物理交换机。当该交换机发生故障时，两个租户同时断网。后续整改中，该平台为 Gold 租户部署了独立 ToR 交换机，实现了真正的网络故障域隔离。