2. Kubernetes 原生隔离机制:命名空间(Namespace)、资源配额(ResourceQuota)、网络策略(NetworkPolicy)、RBAC权限模型
Kubernetes 本身提供了四层相互独立又彼此互补的原生隔离机制,构成了多租户隔离的基石。理解这四层机制的作用域、配置方式与局限性,是设计多租户集群蓝图的前提。
2.1 命名空间(Namespace):逻辑隔离的第一道边界
Namespace 是 Kubernetes 集群内逻辑上的虚拟分区,它将集群资源划分为多个互不干扰的虚拟集群。每个 Namespace 拥有独立的资源视图,但底层共享同一个物理集群。
| 特性 | 说明 |
|---|---|
| 资源隔离范围 | Pod、Service、Deployment、ConfigMap、Secret 等对象 |
| 不隔离的资源 | Node、PersistentVolume、ClusterRole、ClusterRoleBinding |
| 默认 Namespace | default、kube-system、kube-public、kube-node-lease |
| 创建方式 | kubectl create namespace <name> 或 YAML 定义 |
关键认知:Namespace 仅提供命名隔离和资源视图隔离,不提供网络隔离和权限隔离。同一 Namespace 内的 Pod 默认可以互相通信,不同 Namespace 的 Pod 默认也可以通信(除非 NetworkPolicy 限制)。
# 创建命名空间
kubectl create namespace tenant-alpha
# 查看命名空间中的资源
kubectl get pods -n tenant-alpha
# 切换上下文默认命名空间
kubectl config set-context --current --namespace=tenant-alpha
2.2 资源配额(ResourceQuota):硬性资源上限管控
ResourceQuota 作用于 Namespace 级别,限制该 Namespace 内所有 Pod 可使用的计算资源总量(CPU、内存)和对象数量(Pod、Service、PVC 等)。它是防止单个租户资源抢占的关键手段。
核心配置字段:
requests.cpu/requests.memory:所有 Pod 请求资源总和上限limits.cpu/limits.memory:所有 Pod 限制资源总和上限count/pods/count/services:对象数量上限persistentvolumeclaims:PVC 数量上限
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-quota
namespace: tenant-alpha
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
count/pods: "20"
count/services: "10"
persistentvolumeclaims: "5"
常见陷阱:ResourceQuota 只限制总量,不限制单个 Pod 的资源规格。如果未配合 LimitRange 使用,单个 Pod 可能申请全部配额,导致其他 Pod 无法调度。建议 ResourceQuota 与 LimitRange 组合使用。
2.3 网络策略(NetworkPolicy):细粒度网络访问控制
NetworkPolicy 是 Kubernetes 原生的网络隔离机制,基于标签选择器定义 Pod 之间、Pod 与外部之间的流量规则。默认情况下,Kubernetes 集群内所有 Pod 可以互相通信(全通模型),NetworkPolicy 将其转变为白名单模型。
# 拒绝所有入站流量(默认隔离)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: tenant-alpha
spec:
podSelector: {}
policyTypes:
- Ingress
# 允许来自 frontend 标签的 Pod 访问 backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: tenant-alpha
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
网络策略生效前提:集群必须安装支持 NetworkPolicy 的 CNI 插件,如 Calico、Cilium、Weave Net 等。Flannel 默认不支持 NetworkPolicy。
2.4 RBAC 权限模型:精细化操作权限控制
RBAC(Role-Based Access Control)是 Kubernetes 的授权机制,通过角色(Role/ClusterRole)与绑定(RoleBinding/ClusterRoleBinding)控制用户或服务账户对资源的操作权限。它是多租户隔离中权限隔离的核心。
# 创建 Role:只读访问 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: tenant-alpha
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
# 创建 RoleBinding:将 Role 绑定到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: tenant-alpha
name: read-pods-binding
subjects:
- kind: User
name: "alice@example.com"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
2.5 四层隔离机制对比总结
| 隔离维度 | 机制 | 作用范围 | 隔离强度 | 是否默认启用 |
|---|---|---|---|---|
| 资源视图隔离 | Namespace | 集群级逻辑分区 | 弱(仅命名隔离) | 是 |
| 资源用量隔离 | ResourceQuota | Namespace | 中(总量限制) | 否 |
| 网络流量隔离 | NetworkPolicy | Pod 级别 | 强(白名单模型) | 否(需 CNI 支持) |
| 操作权限隔离 | RBAC | Namespace / 集群 | 强(细粒度 API 控制) | 是(默认 RBAC 启用) |
多租户隔离设计原则:单一机制无法实现完整的多租户隔离。必须组合使用 Namespace + ResourceQuota + NetworkPolicy + RBAC,并配合 LimitRange、PodSecurityPolicy(或 Pod Security Admission)等辅助机制,才能构建生产级的多租户隔离方案。