3. 多租户模型设计：Namespace隔离、RBAC策略、ResourceQuota、LimitRange在CAPI中的应用

在CAPI（Cluster API）管理的大规模多租户环境中，租户之间的资源隔离、权限控制和配额管理是保障集群稳定性和安全性的基石。Kubernetes原生的Namespace、RBAC、ResourceQuota和LimitRange机制，结合CAPI的声明式集群管理能力，能够构建出自动化、可扩展的多租户模型。本章将深入剖析这四大核心组件在CAPI场景下的设计原则与实现路径。

3.1 多租户隔离层次模型

多租户隔离并非单一维度的操作，而是从集群、命名空间到资源对象的层层递进。在CAPI工作流中，每个租户通常对应一个或多个Namespace，并通过RBAC策略限定其操作边界，再通过ResourceQuota和LimitRange控制资源消耗。下图展示了CAPI多租户模型的核心层次结构：

3.2 Namespace隔离策略

Namespace是Kubernetes多租户隔离的基本单元。在CAPI场景下，每个租户的工作负载、ConfigMap、Secret等资源都应归属于独立的Namespace。CAPI本身也利用Namespace来隔离不同集群的Cluster、Machine、MachineDeployment等资源对象。

3.2.1 租户Namespace命名规范

建议采用统一的命名模式，便于自动化管理和策略匹配：

3.2.2 CAPI资源与租户Namespace的映射

CAPI管理的集群资源（Cluster、Machine等）通常位于管理集群的特定Namespace中。租户工作负载则位于目标集群的租户Namespace中。这种双层Namespace结构需要清晰的映射关系：

# 管理集群侧：CAPI资源位于 tenant-clusters 命名空间
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: tenant-001-cluster
  namespace: tenant-clusters
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.96.0.0/12"]
    serviceDomain: "cluster.local"
  # ... 其他配置

---
# 目标集群侧：租户工作负载位于 tenant-001 命名空间
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-001
  labels:
    tenant-id: "001"
    environment: "production"

3.3 RBAC策略设计

RBAC（基于角色的访问控制）是Kubernetes中实现细粒度权限管理的核心机制。在多租户CAPI环境中，RBAC策略需要覆盖两个层面：管理集群层面的CAPI资源访问控制，以及目标集群层面的租户资源访问控制。

3.3.1 管理集群RBAC：CAPI资源访问

平台管理员需要创建针对CAPI资源的ClusterRole，并绑定到不同的租户管理员或运维人员：

# 租户管理员角色：允许管理自己的Cluster和Machine资源
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tenant-admin
rules:
- apiGroups: ["cluster.x-k8s.io"]
  resources: ["clusters", "machines", "machinedeployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["infrastructure.cluster.x-k8s.io"]
  resources: ["awsclusters", "awsclustertemplates"]
  verbs: ["get", "list", "watch"]

---
# 绑定到特定租户的ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-001-admin-binding
  namespace: tenant-clusters
subjects:
- kind: ServiceAccount
  name: tenant-001-sa
  namespace: tenant-clusters
roleRef:
  kind: ClusterRole
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io

3.3.2 目标集群RBAC：租户工作负载访问

在目标集群中，每个租户应拥有独立的ServiceAccount和Role，限定其只能操作自己Namespace内的资源：

# 目标集群中的租户角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tenant-role
  namespace: tenant-001
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["autoscaling"]
  resources: ["horizontalpodautoscalers"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3.4 ResourceQuota与LimitRange配置

ResourceQuota和LimitRange是防止租户资源滥用、保障集群公平性的关键工具。在CAPI多租户模型中，这两个资源需要在目标集群创建时自动部署到每个租户Namespace中。

3.4.1 ResourceQuota：总量控制

ResourceQuota限制租户在Namespace级别可以消耗的资源总量。以下是一个典型的租户配额配置：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-001
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "5"
    pods: "50"
    services: "10"
    configmaps: "20"
    secrets: "20"

3.4.2 LimitRange：单个Pod约束

LimitRange定义Namespace内单个Pod或容器的资源默认值和上下限，防止单个Pod占用过多资源：

apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-001
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

3.4.3 配额与限制的对比

3.5 CAPI中的自动化策略注入

CAPI的ClusterResourceSet机制是实现多租户策略自动化的核心。它允许在目标集群创建或更新时，自动应用一组预定义的Kubernetes资源。下图展示了自动化策略注入的完整流程：

3.5.1 ClusterResourceSet配置示例

以下是一个完整的ClusterResourceSet配置，它会在匹配标签的Cluster创建时，自动注入租户策略：

apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: tenant-policy-set
  namespace: tenant-clusters
spec:
  clusterSelector:
    matchLabels:
      tenant-type: "multi-tenant"
  resources:
  - kind: ConfigMap
    name: tenant-namespace-template
  - kind: ConfigMap
    name: tenant-rbac-template
  - kind: ConfigMap
    name: tenant-quota-template
  - kind: ConfigMap
    name: tenant-limits-template
  strategy: ApplyOnce

3.5.2 策略模板ConfigMap示例

将策略资源定义为ConfigMap，支持模板化变量替换：

apiVersion: v1
kind: ConfigMap
metadata:
  name: tenant-namespace-template
  namespace: tenant-clusters
data:
  namespace.yaml: |
    apiVersion: v1
    kind: Namespace
    metadata:
      name: ${TENANT_NAMESPACE}
      labels:
        tenant-id: ${TENANT_ID}
        environment: ${TENANT_ENV}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tenant-quota-template
  namespace: tenant-clusters
data:
  quota.yaml: |
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: tenant-quota
      namespace: ${TENANT_NAMESPACE}
    spec:
      hard:
        requests.cpu: "${QUOTA_CPU}"
        requests.memory: "${QUOTA_MEMORY}"
        pods: "${QUOTA_PODS}"

3.6 多租户性能调优考量

在CAPI多租户环境中，性能调优需要关注以下关键点：

• API Server负载：大量租户Namespace和RBAC对象会增加API Server的存储和响应压力。建议使用etcd压缩和API优先级与公平性（APF）进行优化。
• 资源配额粒度：ResourceQuota的硬限制可能导致租户Pod调度失败。建议结合Cluster Autoscaler动态扩缩节点池，避免配额成为瓶颈。
• RBAC缓存：频繁的RBAC评估会影响API Server性能。合理使用ClusterRoleBinding（而非大量RoleBinding）可以减少授权检查开销。
• LimitRange默认值：合理的默认值可以减少Pod因缺少资源声明而被拒绝的概率。建议根据历史监控数据动态调整默认值。

3.7 本章小结