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