多租户架构基础：多租户定义、租户隔离模型与资源配额管理

在云原生与 GitOps 实践中，多租户架构是支撑企业级平台复用、成本分摊与安全隔离的核心设计。本章从定义出发，逐步拆解租户隔离的三种模型，并给出资源配额管理的具体实现方法。

2.1 多租户定义

多租户（Multi-Tenancy）是指同一套 Kubernetes 集群或控制平面同时服务于多个独立业务单元（租户），每个租户在逻辑上拥有专属的工作负载、网络策略与资源视图，但共享底层基础设施。多租户的核心目标是：

• 成本分摊：通过共享集群降低运维与资源开销。
• 安全隔离：防止租户间越权访问或资源争抢。
• 运维效率：统一升级、监控与 GitOps 同步策略。

2.2 租户隔离模型

根据隔离粒度与安全等级，Kubernetes 多租户通常分为三种模型。下表对比了各模型的核心特征：

2.2.1 命名空间隔离（Namespace Isolation）

最轻量的隔离方式。每个租户分配一个或多个 Namespace，通过 RBAC、NetworkPolicy、ResourceQuota 实现访问与资源限制。优点是无额外控制平面开销，缺点是共享 API Server 与节点，存在一定的爆炸半径风险。

2.2.2 集群隔离（Cluster Isolation）

每个租户拥有独立的 Kubernetes 集群。隔离最彻底，但管理成本与资源碎片率最高。适用于对安全与合规有严格要求的场景，如金融核心交易、医疗数据。

2.2.3 控制平面隔离（Control Plane Isolation）

通过虚拟集群技术（如 vCluster、Kiosk、Virtual Kubelet）为每个租户提供独立的 API 控制平面，但共享底层节点与数据平面。租户看到的是完整 Kubernetes API，但实际资源调度在宿主集群上。这是成本与隔离之间的最佳平衡点，也是本课程后续同步波次编排的主要目标模型。

2.3 租户资源配额管理

无论采用哪种隔离模型，资源配额都是防止租户“吵闹邻居”效应的关键手段。Kubernetes 原生提供 ResourceQuota 与 LimitRange 对象，在 GitOps 多租户场景下，配额管理需要与租户生命周期自动化绑定。

2.3.1 核心配额对象

2.3.2 租户配额配置示例

以下是一个典型的租户 ResourceQuota 配置，适用于命名空间隔离模型：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-alpha
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    requests.storage: "50Gi"
    persistentvolumeclaims: "10"
    count/deployments: "15"
    count/services: "10"

2.3.3 配额管理最佳实践

• 配额与租户绑定：在 GitOps 仓库中为每个租户目录维护独立的 quota.yaml，通过 ArgoCD ApplicationSet 或 Flux Kustomization 自动同步。
• 预留与限制分离：requests 保证调度，limits 防止突发占用。建议 limits 为 requests 的 1.5~2 倍。
• 对象数量限制：防止租户创建过多小对象导致 etcd 压力，尤其要限制 count/secrets 与 count/configmaps。
• 动态调整：结合成本监控数据，定期调整配额。在同步波次编排中，可将配额更新作为波次前置检查。

2.4 隔离模型选型建议

在实际项目中，选择哪种隔离模型取决于安全要求、运维成本与资源利用率的平衡。以下决策树可辅助判断：

1. 租户是否互信？（如内部团队）→ 命名空间隔离 + 严格 RBAC。
2. 租户是否需要独立 API 视图？（如外部客户）→ 控制平面隔离。
3. 是否有合规审计要求？（如金融、医疗）→ 集群隔离。
4. 成本敏感且租户数量大？（如 SaaS 平台）→ 控制平面隔离 + 资源配额。