2. 多租户架构基础：租户定义、资源隔离模型与故障域概念
在多租户 Kubernetes 集群中，租户 并非 Kubernetes 原生 API 对象，而是一种逻辑边界。SRE 团队需要将租户映射到具体的资源隔离单元，并理解故障域对演练一致性的影响。本节从三个核心维度展开：租户定义、资源隔离模型（Namespace / Cluster / Region）、故障域概念。
2.1 租户定义与身份标识
租户代表一个独立的业务单元或团队，拥有专属的计算、存储、网络资源以及访问控制策略。在 Argo CD 多租户场景中，租户通常通过以下方式标识：
| 标识维度 | 典型实现 | Argo CD 映射 |
|---|---|---|
| Kubernetes Namespace | 每个租户独占一个或多个 Namespace | AppProject 限制目标 Namespace |
| Cluster 标签 | 租户绑定到特定集群（如 prod-tenant-a） | Cluster 级别 RBAC + 项目绑定 |
| Region 分区 | 租户资源部署在特定地理区域 | 多集群 + 多 Region 的 ApplicationSet |
| RBAC 组 | LDAP/OIDC 组映射到 Argo CD 角色 | argocd-rbac-cm 中的 policy.csv |
关键原则： 租户定义必须与故障域边界对齐。如果两个租户共享同一个故障域（如同一 Node 或同一可用区），则故障演练时无法实现真正的隔离验证。
2.2 资源隔离模型：Namespace / Cluster / Region
Kubernetes 多租户隔离通常分为三个层级，每个层级对应不同的故障域粒度和 Argo CD 管理策略：
- Namespace 级隔离：最轻量，通过 ResourceQuota、NetworkPolicy、RBAC 实现。适用于开发/测试环境，故障域为单节点或单可用区。Argo CD 通过 AppProject 的
sourceNamespaces和destinations限制。 - Cluster 级隔离：每个租户独占一个 Kubernetes 集群，物理或虚拟。故障域为整个集群（控制面 + 数据面）。Argo CD 通过多集群注册 + 项目绑定实现。
- Region 级隔离：租户资源跨多个地理区域部署，故障域为整个区域（如 AWS us-east-1）。Argo CD 通过 ApplicationSet 的
generators中的clusters或git生成器实现。
2.3 故障域概念与多租户映射
故障域 是指系统中一组共享单点故障风险的组件集合。在 Kubernetes 中，常见的故障域包括：
- 物理故障域：机架、电源、网络交换机、数据中心。
- 逻辑故障域：Kubernetes 控制面、etcd 集群、Ingress Controller。
- 云故障域：可用区（AZ）、区域（Region）、边缘站点。
多租户架构要求每个租户的资源分布在 独立的故障域 中，否则一个故障可能影响多个租户。下表展示了租户与故障域的典型映射关系：
| 租户类型 | 推荐隔离层级 | 故障域要求 | Argo CD 一致性复核要点 |
|---|---|---|---|
| 开发/测试租户 | Namespace 级 | 至少 2 个可用区 | 检查 AppProject 的 destinations 是否限制正确 |
| 生产核心租户 | Cluster 级 | 独立集群 + 跨可用区 | 验证 Cluster 注册信息与 Argo CD 项目绑定 |
| 合规敏感租户 | Region 级 | 数据驻留区域隔离 | ApplicationSet 的 generators 是否按 Region 过滤 |
常见陷阱： 即使租户使用不同的 Namespace，如果 Pod 调度到同一 Node 或同一可用区，故障演练时仍可能相互影响。SRE 需结合 PodAntiAffinity、TopologySpreadConstraints 和 PDB 来强化故障域隔离。
2.4 故障域隔离对 Argo CD 一致性复核的影响
当多租户故障域隔离演练导致资源变更（如扩缩容、迁移、配置更新）后，Argo CD 的一致性复核必须覆盖以下维度：
- 租户边界完整性：变更是否只影响目标租户的 Namespace/Cluster/Region？Argo CD Application 的
spec.destination.namespace和spec.destination.server是否仍指向正确的隔离单元？ - 故障域分布验证：演练后的 Pod 分布是否仍满足故障域要求？可通过
kubectl get pods -o wide --all-namespaces结合节点拓扑标签复核。 - Argo CD Sync 状态一致性：所有受影响的 Application 是否处于
Synced状态？是否存在OutOfSync或SyncFailed？ - 健康状态与故障域关联：Application 的
health.status是否因故障域变更而出现异常？例如，跨 Region 演练后，某 Region 的 Application 健康检查失败。
SRE 最佳实践： 在 Argo CD 中为每个租户创建独立的 AppProject，并在项目级别设置
clusterResourceWhitelist 和 namespaceResourceBlacklist。演练后，通过 Argo CD API 批量查询所有 Application 的 status.sync.status 和 status.health.status，并与故障域标签做交叉比对。