3. 故障域隔离演练概述
在多租户 Kubernetes 集群中，故障域隔离是保障租户 SLA 与数据安全的核心能力。故障域隔离演练通过主动注入故障，验证集群基础设施与 Argo CD 配置是否能在真实故障场景下维持租户工作负载的隔离性与一致性。本节从演练目的与常见场景两个维度展开，为后续资源变更后的一致性复核奠定理论基础。
3.1 演练目的
故障域隔离演练的核心目标可归纳为两个关键验证项：
| 验证维度 | 具体目标 | 验证方法 |
|---|---|---|
| 隔离性验证 | 确保单个故障域（如 AZ、节点）失效时，仅影响该域内的租户工作负载，不扩散至其他域 | 注入故障后，检查非故障域 Pod 的可用性、网络连通性及数据面状态 |
| 配置漂移发现 | 检测因故障域切换或资源重建导致的 Argo CD Application 与集群实际状态之间的差异 | 使用 argocd app diff 对比 Git 声明式配置与集群实时资源 |
关键指标： 演练结束后，非故障域租户的 Pod 可用率 ≥ 99.9%，Argo CD 检测到的配置漂移项 ≤ 0（即完全一致）。
3.2 常见故障场景
根据生产环境多租户集群的典型故障模式，以下三种场景被纳入演练范围：
- AZ 故障： 模拟整个可用区（Availability Zone）的网络或电源中断，验证跨 AZ 部署的租户工作负载能否自动迁移至健康 AZ。
- 节点故障： 模拟单节点或节点组（Node Group）的硬件/软件崩溃，验证 Pod 驱逐与重新调度后，租户资源标签、亲和性规则是否被正确保留。
- 网络分区： 模拟集群内部或集群与 Git 仓库之间的网络隔离，验证 Argo CD 在离线状态下是否保持最后一次同步状态，以及恢复后能否自动修复漂移。
3.3 故障域隔离演练流程
下图展示了故障域隔离演练的完整流程，从故障注入到一致性复核的闭环路径：
3.4 场景对比与演练优先级
不同故障场景对租户工作负载的影响程度与恢复策略存在差异，下表总结了各场景的关键特征：
| 场景 | 影响范围 | 恢复策略 | Argo CD 一致性风险 | 演练优先级 |
|---|---|---|---|---|
| AZ 故障 | 跨 AZ 部署的租户 | Pod 自动迁移至健康 AZ | 高（节点亲和性、PV 挂载可能漂移） | P0 |
| 节点故障 | 单节点上的租户 Pod | Kubernetes 驱逐 + 重新调度 | 中（资源标签、资源配额可能丢失） | P1 |
| 网络分区 | 集群内或 Git 仓库连通性 | 网络恢复后自动同步 | 低（Argo CD 保持最后同步状态） | P2 |
最佳实践： 建议按 P0 → P1 → P2 的顺序逐步开展演练。每次演练后，必须执行 argocd app diff 与 argocd app sync 确保一致性，并将结果记录至演练报告。
3.5 演练前置条件检查清单
在开始故障注入前，SRE 团队应确认以下条件已满足：
- Argo CD 已配置多集群管理，且目标集群处于 Healthy 状态。
- 所有租户 Application 的 Sync Status 为 Synced，无 OutOfSync 项。
- 故障域（AZ/节点/网络）已通过 topology.kubernetes.io/zone 或 kubernetes.io/hostname 标签明确标识。
- 租户工作负载已配置 PodDisruptionBudget 与 topologySpreadConstraints。
- 演练回滚方案已就绪，包括快速恢复脚本与 Argo CD 回滚命令。
# 示例：检查 Argo CD Application 同步状态
argocd app list --project tenant-a --output json | jq '.[] | {name: .metadata.name, sync: .status.sync.status, health: .status.health.status}'