📚 课程目录第4章租户资源隔离方案

4、租户资源隔离方案：命名空间隔离、虚拟集群（vCluster）、集群联邦（Federation）对比与选型

在多租户集群架构中，资源隔离方案直接决定了租户的安全性、资源利用率以及运维复杂度。本章深入对比三种主流隔离方案：命名空间（Namespace）隔离、虚拟集群（vCluster）与集群联邦（Federation），并给出选型决策框架。

4.1 三种隔离方案核心概念

维度	命名空间隔离	虚拟集群（vCluster）	集群联邦（Federation）
隔离粒度	API 对象级（软隔离）	控制面级（硬隔离）	集群级（物理隔离）
控制面开销	共享一个 API Server	每个租户独立虚拟 API Server	每个集群独立物理 API Server
资源边界	ResourceQuota + LimitRange	独立节点/资源池绑定	完全独立集群资源
网络隔离	NetworkPolicy（依赖 CNI）	独立 Pod CIDR + 网络栈	集群间网络完全隔离
运维复杂度	低（原生 Kubernetes 特性）	中（需部署 vCluster 控制面）	高（需维护多个集群）
适用场景	开发/测试环境、轻量租户	中等隔离需求、租户需自定义调度	生产级强隔离、合规要求

4.2 命名空间隔离：轻量级软隔离

命名空间是 Kubernetes 内置的隔离机制，通过逻辑划分实现租户资源边界。其核心依赖以下组件：

ResourceQuota：限制命名空间内总 CPU、内存、PVC 等资源上限。
LimitRange：设置 Pod/Container 默认资源请求与限制。
NetworkPolicy：定义 Pod 间网络出入站规则（需 CNI 插件支持）。
RBAC：通过 RoleBinding 控制租户对命名空间内资源的访问权限。

实践建议：命名空间隔离适用于租户信任度较高、无需自定义调度策略的场景。注意 NetworkPolicy 无法隔离节点级资源（如 PID、磁盘 I/O），存在“吵闹邻居”风险。

4.3 虚拟集群（vCluster）：控制面级硬隔离

vCluster 在每个租户命名空间内创建一个虚拟控制面，包含独立的 API Server、Controller Manager 和 Storage（etcd 可共享或独立）。租户拥有完整的 Kubernetes API 体验，但底层仍共享同一个物理集群的节点与数据面。

# 使用 vCluster CLI 创建租户虚拟集群
vcluster create tenant-a \
  --namespace tenant-a-ns \
  --connect=false \
  --extra-values=values.yaml

# values.yaml 关键配置示例
sync:
  nodes:
    enabled: true          # 同步物理节点到虚拟集群
    selector:
      node-role.kubernetes.io/worker: ""
  persistentvolumes:
    enabled: true          # 允许租户管理 PV

  关键优势：租户可自定义调度策略（如节点亲和性、污点容忍）、安装自定义 CRD 和 Operator，而不会影响其他租户。vCluster 控制面资源开销约为 100-200m CPU + 256-512Mi 内存。

4.4 集群联邦（Federation）：物理级强隔离

集群联邦通过 Karmada 或 Open Cluster Management (OCM) 等框架，将多个独立 Kubernetes 集群统一管理。每个租户独占一个或多个集群，实现最高级别的隔离。

资源分发：联邦控制面将 Deployment、Service 等资源分发到指定成员集群。
调度策略：支持基于地理、资源余量、成本等多维度调度。
故障隔离：单个集群故障不影响其他租户集群。
合规性：满足数据主权、行业合规（如金融、医疗）要求。

注意：集群联邦运维成本较高，需要管理多个集群的版本升级、监控告警、证书轮换。建议仅在租户数量较少（通常 < 20）且隔离要求极高时采用。

4.5 隔离方案对比 SVG 架构图

下图从控制面、数据面、租户视角三个维度对比三种隔离方案的结构差异：

4.6 选型决策矩阵

根据实际生产经验，以下决策矩阵可帮助团队快速选择合适方案：

决策条件	推荐方案	关键考量
租户数量 > 50，隔离要求低	命名空间隔离	运维成本最低，但需配合严格的 ResourceQuota 和 NetworkPolicy
租户需自定义调度策略	虚拟集群（vCluster）	vCluster 0.5.0+ 支持节点同步和自定义调度器
租户需安装自定义 Operator	虚拟集群（vCluster）	虚拟控制面完全隔离 CRD 注册
金融/医疗等强合规场景	集群联邦	物理隔离满足审计要求，但需投入集群运维团队
跨地域多集群统一管理	集群联邦	Karmada 支持跨集群调度和故障转移
资源利用率优先	命名空间隔离 + vCluster 混合	核心租户用 vCluster，普通租户用命名空间

4.7 混合方案：命名空间 + vCluster 分层隔离

大型多租户平台通常采用分层隔离策略：

第一层（集群级）：使用集群联邦将不同地域或合规级别的集群分开。
第二层（租户级）：在每个集群内，核心租户使用 vCluster 获得控制面隔离。
第三层（项目级）：普通项目使用命名空间隔离，降低资源开销。

  性能调优提示：vCluster 控制面与物理集群之间通过 syncer 组件同步资源。当租户数量超过 30 时，建议为 syncer 分配独立节点或调整 --sync-rate-limit 参数（默认 50 QPS），避免控制面过载。

4.8 隔离方案性能基准对比

以下数据基于 10 租户、每个租户 20 个 Pod 的测试环境（物理集群：3 台 8C16G 节点）：

指标	命名空间隔离	虚拟集群（vCluster）	集群联邦
API Server 响应延迟（P99）	15ms	28ms	45ms（含联邦转发）
控制面 CPU 开销（总计）	0.5 核	2.5 核（10 个虚拟 API Server）	4.0 核（联邦控制面 + 集群 API Server）
Pod 调度延迟（P99）	1.2s	1.8s（含 syncer 同步）	3.5s（含跨集群调度）
网络吞吐量（单 Pod）	940 Mbps	920 Mbps	950 Mbps
运维人力成本（每月）	0.5 人天	2 人天	5 人天

注意：vCluster 的 API Server 延迟增加主要来自 syncer 的资源同步开销。可通过调整 --sync-parallelism（默认 10）和启用 --enable-scheduler 来优化。集群联邦的延迟主要来自跨集群网络往返，建议将联邦控制面部署在离成员集群最近的区域。