3、虚拟集群与租户级控制平面

在传统多租户 Kubernetes 集群中，所有租户共享同一个控制平面（API Server、Controller Manager、Scheduler）。这种架构存在明显的隔离短板：租户间的 API 请求无法做到物理隔离，一个租户的异常流量或恶意操作可能影响整个集群的控制面稳定性。虚拟集群（Virtual Cluster）与租户级控制平面正是为解决这一痛点而生——每个租户获得一个逻辑上独立的控制平面，而底层计算资源仍共享同一个物理集群。

3.1 虚拟集群架构

虚拟集群并非创建完整的物理 Kubernetes 集群，而是在共享的“超级集群”（Super Cluster）之上，为每个租户实例化一套轻量级控制平面组件。租户的 API Server、Controller Manager 甚至 Scheduler 都以 Pod 形式运行在超级集群的命名空间中，但对外表现为一个独立的 Kubernetes 集群端点。

下图展示了虚拟集群的典型分层架构：

3.2 租户专属 API Server

租户专属 API Server 是虚拟集群的核心组件。它本质上是一个标准 kube-apiserver 进程，但通过以下定制实现租户隔离：

部署租户 API Server 时，通常使用 Helm Chart 或 Operator 自动生成以下核心资源：

# 租户 API Server 部署示例（简化）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-apiserver-tenant-a
  namespace: tenant-control-planes
spec:
  replicas: 2
  selector:
    matchLabels:
      app: kube-apiserver
      tenant: tenant-a
  template:
    metadata:
      labels:
        app: kube-apiserver
        tenant: tenant-a
    spec:
      containers:
      - name: kube-apiserver
        image: registry.k8s.io/kube-apiserver:v1.28.0
        command:
        - kube-apiserver
        - --advertise-address=$(POD_IP)
        - --etcd-servers=https://etcd-cluster:2379
        - --etcd-prefix=/tenant-a/
        - --service-cluster-ip-range=10.96.0.0/16
        - --client-ca-file=/etc/kubernetes/pki/tenant-a/ca.crt
        - --tls-cert-file=/etc/kubernetes/pki/tenant-a/apiserver.crt
        - --tls-private-key-file=/etc/kubernetes/pki/tenant-a/apiserver.key
        - --authorization-mode=RBAC,Webhook
        - --audit-log-path=/var/log/audit/tenant-a.log
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
          limits:
            cpu: 2
            memory: 4Gi
        volumeMounts:
        - name: tenant-certs
          mountPath: /etc/kubernetes/pki/tenant-a
      volumes:
      - name: tenant-certs
        secret:
          secretName: tenant-a-certs

3.3 租户控制平面生命周期管理

租户控制平面的生命周期管理是虚拟集群运维的核心挑战。一个成熟的实现通常包含以下阶段：

1. 预置（Provisioning）： 租户注册后，控制平面 Operator 自动生成 CA 证书、etcd 前缀、RBAC 初始角色、网络策略和资源配额。整个过程应在 30 秒内完成。
2. 启动（Startup）： 依次启动 etcd 代理（或确认前缀可用）、API Server、Controller Manager。Scheduler 可选——租户可复用超级集群调度器，也可运行专属调度器。
3. 运行（Runtime）： 持续监控 API Server 健康状态、etcd 存储用量、请求延迟和错误率。自动扩缩容 API Server 副本数（HPA）。
4. 升级（Upgrade）： 支持滚动升级租户控制平面版本，不中断租户工作负载。升级顺序：etcd → API Server → Controller Manager。
5. 回收（Teardown）： 租户退订时，优雅关闭 API Server，清理 etcd 数据、证书 Secret、Service 和关联资源。数据保留策略可配置（如保留 7 天）。

下表对比了三种主流的租户控制平面生命周期管理方案：

下图展示了 Operator 驱动模式下租户控制平面的完整生命周期状态机：