2、多租户架构基础：Kubernetes多租户模型与CAPI隔离设计

多租户架构是云原生平台实现资源隔离、安全管控与成本分摊的核心能力。在CAPI（Cluster API）管理环境中，租户隔离不仅涉及Kubernetes原生的Namespaces、RBAC与NetworkPolicy，还需要在集群生命周期管理层面贯彻隔离设计原则。本节将系统梳理Kubernetes多租户模型的关键组件，并提炼CAPI场景下的租户隔离设计原则。

2.1 Kubernetes多租户模型三大支柱

Kubernetes本身并未提供“租户”这一原生对象，而是通过以下三种机制的组合来实现多租户隔离：

2.2 Namespaces：逻辑租户边界

Namespaces是Kubernetes中最基础的多租户隔离单元。每个Namespace可以包含独立的Pod、Service、ConfigMap、Secret等资源，并通过ResourceQuota对象限制租户的资源消耗上限。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-a
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

2.3 RBAC：细粒度权限控制

RBAC（基于角色的访问控制）是Kubernetes多租户安全的核心。通过Role与RoleBinding的组合，可以实现Namespace级别的权限隔离；ClusterRole与ClusterRoleBinding则用于集群级别的权限管理。

• Role：定义在特定Namespace内的操作权限（如get、list、create、delete）。
• ClusterRole：定义集群范围内的操作权限，或跨Namespace的资源访问。
• RoleBinding：将Role绑定到用户、组或ServiceAccount，作用域限定在Namespace内。
• ClusterRoleBinding：将ClusterRole绑定到主体，作用域为整个集群。

2.4 NetworkPolicy：网络层硬隔离

NetworkPolicy通过标签选择器和IP段规则，控制Pod之间的网络通信。默认情况下，Kubernetes集群允许所有Pod互相通信；启用NetworkPolicy后，未显式允许的流量将被拒绝。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-monitoring
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
      podSelector:
        matchLabels:
          app: prometheus

2.5 CAPI中的租户隔离设计原则

在CAPI管理环境下，租户隔离需要从集群生命周期、资源分配、安全边界三个维度进行设计。以下为五大核心原则：

1. 集群级隔离优先：对于安全要求高的租户，应分配独立的CAPI工作集群（Cluster对象），而非共享集群内的Namespace。CAPI的Cluster API支持快速创建和销毁集群，适合租户级硬隔离。
2. Namespace配额标准化：在共享集群场景中，通过ClusterResourceQuota或ResourceQuota模板，确保每个租户的Namespace创建时自动绑定资源上限。
3. RBAC最小权限原则：CAPI的Cluster API本身需要较高的集群管理权限，但租户对工作集群的操作应严格限制在自身Namespace内。使用CAPI的RBAC代理或OIDC集成实现身份映射。
4. 网络策略默认拒绝：在CAPI Cluster manifest中，通过ClusterResourceSet或ConfigMap预置默认的NetworkPolicy，实现租户间网络隔离。
5. 审计与监控隔离：每个租户的审计日志、监控指标应独立存储，避免跨租户数据泄露。CAPI的Cluster API支持为每个集群配置独立的Prometheus实例或日志收集器。

2.6 CAPI多租户隔离架构图

下图展示了CAPI管理平面与工作集群之间的多租户隔离关系：

2.7 租户隔离策略对比

2.8 租户资源配额调优前置检查清单

在进入具体的配额调优之前，建议完成以下检查项，确保多租户基础架构就绪：

• Namespace规划：是否已为每个租户创建独立的Namespace？命名规范是否统一（如 tenant-{id}）？
• ResourceQuota绑定：每个Namespace是否已绑定ResourceQuota？配额值是否基于租户SLA设定？
• RBAC配置：租户的ServiceAccount是否仅拥有自身Namespace的操作权限？是否禁用了集群级别的ClusterRole？
• NetworkPolicy生效：是否已部署默认拒绝所有入站流量的NetworkPolicy？是否允许监控系统跨Namespace访问？
• CAPI Cluster manifest：Cluster对象的spec中是否指定了支持NetworkPolicy的CNI？是否通过ClusterResourceSet预置了配额模板？