3、多租户模型基础:命名空间、RBAC、NetworkPolicy、ResourceQuota

多租户隔离是 Kubernetes 平台控制面实现 API 限流与队列隔离的前提。本章聚焦四个核心原语:命名空间(Namespace)作为租户边界、RBAC 作为权限墙、NetworkPolicy 作为网络微隔离、ResourceQuota 作为资源硬约束。这四个原语共同构成多租户模型的“四梁八柱”。

3.1 命名空间:租户的逻辑边界

命名空间是 Kubernetes 中实现多租户隔离的第一层抽象。每个命名空间相当于一个虚拟集群,内部的对象名称天然隔离,且可以独立设置资源配额与访问策略。

特性 说明 多租户意义
名称隔离 同一命名空间内名称唯一,跨命名空间可重名 租户 A 和租户 B 可拥有同名 Service
资源配额绑定 ResourceQuota 作用于命名空间级别 限制每个租户的 CPU/内存/Pod 总数
网络策略作用域 NetworkPolicy 默认只影响本命名空间 租户间默认隔离,按需开放
RBAC 作用域 Role 绑定到命名空间,ClusterRole 可跨空间 细粒度控制租户管理员权限
最佳实践:每个租户分配独立命名空间,命名规范建议采用 {tenant}-{env} 格式,例如 fintech-prod、fintech-staging,便于自动化运维与审计。

3.2 RBAC:细粒度的权限墙

RBAC(基于角色的访问控制)是 Kubernetes 默认的授权机制。在多租户场景下,RBAC 决定了“谁能在哪个命名空间做什么”。核心组件包括:

  • Subject:用户、组或 ServiceAccount。
  • Role / ClusterRole:定义一组权限规则(verbs + resources)。
  • RoleBinding / ClusterRoleBinding:将 Subject 与 Role 绑定。
# 示例:为租户管理员创建命名空间级 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: fintech-prod
  name: tenant-admin
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: fintech-prod
  name: tenant-admin-binding
subjects:
- kind: ServiceAccount
  name: fintech-sa
  namespace: fintech-prod
roleRef:
  kind: Role
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io
安全警告:避免使用 cluster-admin 或通配符 * 权限。多租户环境下,最小权限原则是防止横向越权的第一道防线。建议为每个租户创建专用 ServiceAccount,并通过 RoleBinding 限定到其命名空间。

3.3 NetworkPolicy:网络微隔离

默认情况下,Kubernetes 集群内所有 Pod 可以互相通信。多租户场景必须打破这一默认行为,NetworkPolicy 正是实现 Pod 级网络隔离的标准方式。

关键设计原则:

  • 默认拒绝入站:只允许显式声明的入站流量。
  • 默认拒绝出站:只允许显式声明的出站流量。
  • 命名空间级隔离:通过 namespaceSelector 控制跨命名空间访问。
  • Pod 级隔离:通过 podSelector 控制同一命名空间内的访问。
# 示例:拒绝所有非本命名空间的入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-ns-ingress
  namespace: fintech-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: fintech-prod
多租户网络隔离矩阵:建议为每个租户命名空间打上 tenant: <name> 标签,然后通过 namespaceSelector.matchLabels 实现租户间白名单通信。例如,允许 monitoring 命名空间的 Prometheus 抓取所有租户的 metrics 端点。

3.4 ResourceQuota:资源硬约束

ResourceQuota 是防止租户资源滥用、保障平台稳定性的关键机制。它作用于命名空间级别,可以限制以下维度:

资源类型 示例 说明
计算资源 requests.cpu, limits.memory 限制 Pod 的 CPU/内存请求与上限
存储资源 requests.storage, persistentvolumeclaims 限制 PVC 数量与总存储容量
对象数量 pods, services, configmaps 限制命名空间内各类对象的数量
扩展资源 nvidia.com/gpu 限制 GPU 等特殊硬件资源
# 示例:为租户命名空间设置资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: fintech-prod
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"
    services: "10"
    persistentvolumeclaims: "5"
    requests.storage: "100Gi"
配额与限流的关系:ResourceQuota 是“静态”资源上限,而 API 限流(APF/APIPriorityAndFairness)是“动态”请求控制。两者配合使用:ResourceQuota 防止租户创建过多 Pod 导致节点资源耗尽;API 限流防止租户的 API 请求淹没控制面。后续章节将详细展开 API 限流策略。

3.5 多租户模型架构总览

下图展示了四个原语在多租户模型中的协作关系:命名空间作为租户边界,RBAC 控制用户权限,NetworkPolicy 实现网络隔离,ResourceQuota 约束资源使用。

多租户模型四层隔离架构 租户 A 命名空间 (fintech-prod) 租户 B 命名空间 (health-prod) Pod (App A1) Pod (App A2) Service A ConfigMap Pod (App B1) Pod (App B2) Service B RBAC 权限墙 Role: tenant-admin → ServiceAccount: fintech-sa RBAC 权限墙 Role: tenant-admin → ServiceAccount: health-sa NetworkPolicy 网络隔离 默认拒绝跨命名空间入站 NetworkPolicy 网络隔离 默认拒绝跨命名空间入站 ResourceQuota: CPU 4核 / 内存 8Gi / Pod 20 ResourceQuota: CPU 8核 / 内存 16Gi / Pod 30 四层隔离:命名空间(逻辑边界)→ RBAC(权限墙)→ NetworkPolicy(网络微隔离)→ ResourceQuota(资源硬约束)

3.6 多租户隔离策略对比

隔离维度 Kubernetes 原语 作用范围 默认行为 多租户推荐配置
逻辑边界 Namespace 集群级 名称隔离 每租户独立命名空间
权限控制 RBAC (Role + RoleBinding) 命名空间级 无限制(默认允许) 最小权限 Role,绑定到 ServiceAccount
网络隔离 NetworkPolicy 命名空间级 全通(默认允许) 默认拒绝入站,按需白名单
资源约束 ResourceQuota + LimitRange 命名空间级 无限制 设置 CPU/内存/Pod 硬上限
关键结论:四个原语缺一不可。缺少 RBAC,租户可能越权操作其他命名空间;缺少 NetworkPolicy,恶意 Pod 可以横向扫描;缺少 ResourceQuota,单个租户可能耗尽集群资源导致 DoS。在后续章节中,我们将基于这四层隔离,构建 API 限流与队列隔离策略。