3. 多租户架构基础：租户隔离模型与控制面节点策略

在 Cluster API 驱动的多租户环境中，租户隔离模型与控制面节点策略是决定集群安全性、资源效率和运维复杂度的核心设计决策。本章从隔离模型（软隔离 vs 硬隔离）和控制面节点共享/专用两个维度展开，并引入资源配额与网络策略作为落地手段。

3.1 租户隔离模型：软隔离 vs 硬隔离

租户隔离模型定义了不同租户工作负载之间的边界强度。根据安全等级、合规要求和资源共享程度，分为软隔离（Soft Multi-Tenancy）和硬隔离（Hard Multi-Tenancy）两种模式。

3.2 控制面节点：共享 vs 专用

控制面节点（Control Plane Nodes）承载 kube-apiserver、etcd、controller-manager 和 scheduler。在多租户架构中，控制面节点的部署模式直接影响租户隔离强度和集群稳定性。

3.2.1 共享控制面模式

所有租户共享同一组控制面节点。租户工作负载运行在独立的 Worker 节点上，但 API Server 和 etcd 是公共的。

• 优点： 控制面资源利用率高，etcd 统一管理，升级维护简单。
• 缺点： 租户间的 API 请求相互影响（如大流量租户导致 API Server 过载）；etcd 数据隔离仅依赖 Namespace + RBAC，存在信息泄露风险。
• Cluster API 实现： 使用单个 Cluster 资源，通过 KubeadmControlPlane 管理共享控制面，Worker 节点通过 MachineDeployment 按租户分组。

3.2.2 专用控制面模式

每个租户拥有独立的控制面节点组，包括独立的 etcd 实例和 API Server。

• 优点： 完全隔离，一个租户的控制面故障不影响其他租户；可针对租户定制控制面版本和配置。
• 缺点： 资源开销大（每个控制面至少 3 节点），etcd 集群数量多，运维成本高。
• Cluster API 实现： 每个租户对应一个独立的 Cluster 资源，每个 Cluster 包含独立的 KubeadmControlPlane 和 MachineDeployment。Cluster API 的 ClusterResourceSet 可批量注入租户专属配置。

3.3 资源配额（ResourceQuota）

资源配额是软隔离模式下控制租户资源消耗的核心机制。通过 ResourceQuota 对象，平台管理员可以为每个租户 Namespace 设置 CPU、内存、存储和对象数量的上限。

3.3.1 关键配额维度

3.3.2 Cluster API 中的配额注入策略

在 Cluster API 工作流中，推荐使用 ClusterResourceSet 自动将 ResourceQuota 配置注入到每个租户的 Namespace 中。示例配置如下：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "32Gi"
    limits.cpu: "16"
    limits.memory: "64Gi"
    pods: "50"
    persistentvolumeclaims: "10"
    requests.storage: "500Gi"
    services: "20"
    secrets: "50"
    configmaps: "50"
---
apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: tenant-a-resourceset
spec:
  clusterSelector:
    matchLabels:
      tenant: tenant-a
  resources:
    - kind: ConfigMap
      name: tenant-a-quota
  strategy: ApplyOnce

3.4 网络策略（NetworkPolicy）

网络策略是软隔离模式下实现租户网络隔离的关键手段。通过 NetworkPolicy 对象，可以控制 Pod 之间的流量、Pod 与外部服务的流量，以及租户 Namespace 之间的访问。

3.4.1 多租户网络策略设计原则

• 默认拒绝（Default Deny）： 每个租户 Namespace 默认拒绝所有入站和出站流量，仅允许显式声明的策略。
• 租户内全通： 允许同一租户 Namespace 内的 Pod 互相通信，便于微服务架构。
• 跨租户隔离： 禁止不同租户 Namespace 之间的直接通信，除非通过显式的 API Gateway 或 Service Mesh。
• 控制面访问： 允许租户 Pod 访问 kube-dns 和 kube-apiserver（通过 Service 或 Cluster IP），但限制对 etcd 和 kubelet 的直接访问。

3.4.2 典型租户网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-tenant-internal
  namespace: tenant-a
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: tenant-a
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: tenant-a
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-and-api
  namespace: tenant-a
spec:
  podSelector: {}
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
        - ipBlock:
            cidr: 10.96.0.0/12  # Service CIDR
      ports:
        - protocol: TCP
          port: 6443  # kube-apiserver

3.4.3 网络策略与 CNI 插件兼容性

3.5 隔离模型选择矩阵

以下矩阵帮助你在不同场景下快速选择隔离模型和控制面策略：