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

3. 租户资源隔离方案：基于Namespace的软隔离、基于虚拟集群（vCluster）的硬隔离、基于Cluster API的租户集群动态创建

在多租户Kubernetes集群中，租户资源隔离是保障安全性与稳定性的核心挑战。根据隔离强度、运维复杂度和资源效率，业界形成了三种主流方案：基于Namespace的软隔离、基于虚拟集群（vCluster）的硬隔离、以及基于Cluster API的租户集群动态创建。本节将从架构原理、适用场景、隔离边界和工程落地四个维度进行深度对比。

3.1 基于Namespace的软隔离

Namespace是Kubernetes原生的逻辑隔离单元，通过RBAC、NetworkPolicy、ResourceQuota和LimitRange实现租户间的资源与权限分割。该方案共享同一个控制面（API Server、Scheduler、Controller Manager），因此被称为“软隔离”。

  核心隔离机制：
  RBAC（Role-Based Access Control）： 通过Role/ClusterRole + RoleBinding限制租户对Namespace内资源的操作权限。
NetworkPolicy： 定义Pod之间的网络通信规则，默认拒绝跨Namespace流量。
ResourceQuota： 限制Namespace级别的CPU、内存、PVC、Service等资源总量。
LimitRange： 设置Pod/Container级别的默认资源请求与限制，防止单个Pod抢占过多资源。

适用场景： 企业内部部门隔离、开发/测试/预发布环境、信任度较高的租户共享集群。隔离粒度适中，运维成本低，资源利用率高。

3.2 基于虚拟集群（vCluster）的硬隔离

vCluster在宿主集群内部创建轻量级虚拟控制面，每个租户拥有独立的API Server、资源对象存储（etcd的虚拟化视图）和调度器。租户Pod运行在宿主集群的Workload节点上，但控制面完全隔离，实现“硬隔离”。

关键差异： vCluster不创建真实的etcd集群，而是将资源对象存储在宿主集群的CRD中，因此启动速度极快（秒级），但无法隔离宿主集群的节点级故障。若需要完全物理隔离，需结合Cluster API方案。

隔离维度	Namespace软隔离	vCluster硬隔离	Cluster API动态集群
控制面隔离	共享	虚拟独立	完全独立
etcd隔离	共享	虚拟化（CRD存储）	独立etcd
Pod网络隔离	NetworkPolicy	NetworkPolicy + 虚拟网络	独立CNI
API Server故障域	全局影响	仅影响该vCluster	仅影响该集群
资源开销	极低（仅RBAC/Quota）	中等（每个vCluster约50-100MB内存）	高（完整控制面+etcd）
创建速度	秒级（kubectl create ns）	秒级（vCluster create）	分钟级（Cluster API）

3.3 基于Cluster API的租户集群动态创建

Cluster API是Kubernetes官方子项目，通过声明式API管理Kubernetes集群的完整生命周期（创建、扩缩容、升级、销毁）。在多租户场景中，每个租户获得一个完全独立的Kubernetes集群，包括独立的控制面、etcd、Worker节点和CNI网络。这是隔离性最强的方案，但资源开销和运维复杂度也最高。

  Cluster API核心组件：
  Management Cluster： 运行Cluster API Controller，负责管理所有租户集群的生命周期。
Cluster Resource： 定义集群的顶层配置，包括基础设施提供商（AWS、vSphere、OpenStack等）。
Machine / MachineDeployment： 定义Worker节点的模板和扩缩容策略。
ControlPlane： 定义控制面组件（如KubeadmControlPlane）的配置。

典型工作流： 租户提交Cluster CR → Management Cluster调用基础设施Provider创建虚拟机 → 虚拟机自动加入集群 → 租户获得kubeconfig。整个过程完全自动化，无需人工介入。

3.4 方案选型决策矩阵

在实际工程落地中，需要根据租户规模、安全等级、资源预算和运维能力进行综合选型。以下决策矩阵可作为参考：

评估维度	Namespace软隔离	vCluster硬隔离	Cluster API动态集群
租户数量	100+（单集群极限约5000个Namespace）	50-200（受限于宿主集群CRD存储性能）	10-50（受限于基础设施资源）
安全等级	低（共享控制面，存在API Server DoS风险）	中（控制面隔离，但节点共享）	高（完全独立，物理/虚拟隔离）
资源效率	极高（无额外控制面开销）	高（每个vCluster约50-100MB内存）	低（每个集群至少3台虚拟机）
运维复杂度	低（原生Kubernetes能力）	中（需管理vCluster生命周期）	高（需管理基础设施Provider）
升级策略	全局升级（影响所有租户）	按vCluster独立升级	按集群独立升级
成本	最低	中等	最高

3.5 工程落地最佳实践

在大型多租户平台中，通常采用混合隔离策略：

分层隔离： 使用Cluster API为每个租户创建独立集群（硬隔离），在集群内部使用Namespace进行部门级软隔离。
vCluster作为中间层： 对于中等安全要求的租户，使用vCluster提供控制面隔离，同时保持较高的资源效率。
自动化租户生命周期管理： 结合Cluster API + GitOps（如Flux/ArgoCD），实现租户集群的声明式创建和配置。

避坑指南：

Namespace软隔离无法阻止租户通过HostPath、特权容器等方式逃逸到节点，必须配合Pod Security Admission（PSA）和Seccomp。
vCluster的虚拟化存储（CRD）在大量资源对象时性能下降，建议每个vCluster的资源对象数不超过5000。
Cluster API的集群创建速度受限于基础设施提供商（如AWS EC2启动时间），建议预置虚拟机镜像以加速。

3.6 典型代码示例：vCluster创建与Cluster API集群定义

vCluster创建命令（使用vCluster CLI）：

# 创建名为tenant-a的虚拟集群，使用vCluster v0.19+
vcluster create tenant-a \
  --namespace vcluster-tenant-a \
  --connect=false \
  --extra-values=values.yaml

# 获取租户kubeconfig
vcluster connect tenant-a -n vcluster-tenant-a --update-current=false --server=https://tenant-a.vcluster.example.com

Cluster API集群定义（YAML）：

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: tenant-b-cluster
  namespace: tenants
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.100.0.0/16"]
    services:
      cidrBlocks: ["10.200.0.0/16"]
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: tenant-b-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: tenant-b-aws-cluster
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: tenant-b-aws-cluster
  namespace: tenants
spec:
  region: us-east-1
  sshKeyName: tenant-b-key
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: tenant-b-control-plane
  namespace: tenants
spec:
  replicas: 3
  machineTemplate:
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: AWSMachineTemplate
      name: tenant-b-cp-template
  kubeadmConfigSpec:
    clusterConfiguration:
      controllerManager:
        extraArgs:
          bind-address: "0.0.0.0"
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: tenant-b-worker-md
  namespace: tenants
spec:
  clusterName: tenant-b-cluster
  replicas: 5
  template:
    spec:
      clusterName: tenant-b-cluster
      version: v1.28.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: tenant-b-worker-bootstrap
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: tenant-b-worker-template