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 将其转变为白名单模型。

NetworkPolicy 流量控制模型 Namespace: tenant-alpha Pod A1 app: frontend Pod A2 app: backend 允许 Namespace: tenant-beta Pod B1 app: web 禁止(默认策略) NetworkPolicy 规则要点 • podSelector:选择目标 Pod • ingress/egress:入站/出站规则 • from/to + namespaceSelector + podSelector:跨命名空间控制
# 拒绝所有入站流量(默认隔离)
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)控制用户或服务账户对资源的操作权限。它是多租户隔离中权限隔离的核心。

RBAC 权限模型架构 Subject User / ServiceAccount / Group RoleBinding 绑定 Subject 与 Role Role / ClusterRole 定义权限规则集合 权限规则示例 apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] resourceNames: [] Role vs ClusterRole 作用域 Role:作用于特定 Namespace ClusterRole:作用于整个集群(跨 Namespace) RoleBinding:将 Role 绑定到 Namespace 内的 Subject ClusterRoleBinding:将 ClusterRole 绑定到全局 Subject
# 创建 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)等辅助机制,才能构建生产级的多租户隔离方案。