3. 租户隔离模型设计

在多租户控制面架构中，隔离模型决定了租户之间的资源边界、安全边界与运维边界。不同的隔离粒度直接影响资源利用率、管理复杂度和故障爆炸半径。本章系统分析四种主流隔离模型的设计原理、核心优缺点及选型依据。

3.1 四种隔离模型概述

根据隔离边界在 Kubernetes 架构中的层级，可将租户隔离模型分为以下四类：

3.2 命名空间隔离

命名空间隔离是 Kubernetes 原生提供的最轻量级多租户方案，通过 Namespace 对象划分资源边界，配合 RBAC、NetworkPolicy、ResourceQuota 实现租户隔离。

3.2.1 核心机制

• 资源隔离：每个 Namespace 拥有独立的 Pod、Service、ConfigMap 等资源视图。
• 权限隔离：通过 RBAC Role/ClusterRole 绑定到 Namespace 范围。
• 网络隔离：NetworkPolicy 控制 Namespace 内/间流量。
• 资源配额：ResourceQuota 限制每个 Namespace 的 CPU/内存/PVC 总量。

3.2.2 优缺点分析

3.3 集群隔离

集群隔离为每个租户分配独立的 Kubernetes 集群，实现物理/虚拟化级别的完全隔离。这是最安全但资源开销最大的隔离模型。

3.3.1 核心机制

• 完全独立：每个租户拥有独立的 API Server、etcd、Controller Manager、Scheduler。
• 物理/VM 隔离：Worker 节点不共享，可部署在不同物理机或虚拟机。
• 网络隔离：集群间网络完全独立，通常通过 VPC 或专线隔离。
• 管理独立：每个集群可独立升级、扩缩容、配置。

3.3.2 优缺点分析

3.4 虚拟控制面隔离

虚拟控制面隔离（Virtual Control Plane，VCP）是一种折中方案：租户共享 Worker 节点池，但每个租户拥有独立的控制面组件。典型实现包括 vcluster、Kiosk、KubeVirt 等。

3.4.1 核心机制

• 独立 API Server：每个租户拥有虚拟 API Server，处理租户的 API 请求。
• 共享数据面：所有租户的 Pod 运行在同一个物理节点池上，通过调度策略实现资源分配。
• 资源隔离：通过 ResourceQuota、LimitRange、PriorityClass 实现租户级资源保障。
• 网络隔离：支持 CNI 插件（如 Calico、Cilium）实现租户网络隔离。

3.4.2 优缺点分析

3.5 联邦隔离

联邦隔离通过 Kubernetes Federation（KubeFed）或类似机制，在多个集群之上构建逻辑租户视图。租户资源可以跨集群分布，但通过联邦控制面统一管理。

3.5.1 核心机制

• 联邦控制面：管理跨集群的资源分发、调度和策略。
• 子集群：每个子集群可以是独立集群或虚拟控制面集群。
• 租户映射：租户资源通过联邦资源模板（如 FederatedDeployment）分发到指定子集群。
• 跨集群网络：通常需要 Service Mesh 或 CNI 插件实现跨集群通信。

3.5.2 优缺点分析

3.6 选型决策矩阵

以下矩阵帮助根据业务需求快速选择隔离模型：

3.7 组合隔离策略

在实际生产环境中，通常不会单一使用某一种隔离模型，而是采用分层组合策略：

1. 第一层：集群隔离 —— 按环境（生产/预发/测试）或合规域划分。
2. 第二层：虚拟控制面隔离 —— 在每个集群内为租户提供独立控制面。
3. 第三层：命名空间隔离 —— 在虚拟控制面内按项目/团队划分 Namespace。
4. 第四层：联邦隔离 —— 跨集群统一管理租户资源分发和策略。

3.8 选型检查清单

• 安全合规：是否需要满足 PCI-DSS、HIPAA、GDPR 等合规要求？→ 优先集群隔离。
• 租户规模：租户数是否超过 100？→ 考虑虚拟控制面隔离。
• 资源效率：是否对资源利用率有严格要求？→ 避免纯集群隔离。
• 运维能力：团队是否有能力管理大量集群？→ 集群数超过 20 时需自动化工具。
• 故障容忍：租户故障是否允许影响其他租户？→ 不允许则选择更粗粒度的隔离。
• 地理分布：是否需要跨区域部署？→ 联邦隔离或虚拟控制面隔离 + 多集群。