4. 基于命名空间的隔离方案：Kubernetes Namespace 的隔离边界、NetworkPolicy 实现网络隔离、ResourceQuota 与 LimitRange 实现资源隔离、RBAC 实现权限隔离

Kubernetes Namespace 是构建多租户隔离集群最基础、最常用的逻辑隔离单元。它并非物理或硬边界，而是通过组合多种机制（网络策略、资源配额、权限控制）在共享集群内实现租户间的软隔离。本章将深入剖析 Namespace 的隔离边界，并逐一拆解 NetworkPolicy、ResourceQuota / LimitRange 以及 RBAC 的实现原理与最佳实践。

4.1 Namespace 的隔离边界：逻辑墙与共享宿主机

Namespace 在 Kubernetes 中提供的是 逻辑隔离，而非强安全隔离。它主要隔离了以下资源视图：

• 资源对象名称：同一 Namespace 内资源名称必须唯一，不同 Namespace 可重名。
• 服务发现：通过 <service-name>.<namespace>.svc.cluster.local 跨 Namespace 访问，默认不隔离。
• 资源配额：通过 ResourceQuota 限制 Namespace 级别的总资源消耗。
• 权限边界：RBAC 规则可限定到 Namespace 级别。

但以下方面 默认不隔离，需要额外配置：

• 网络通信：Pod 默认可以跨 Namespace 通信（依赖 CNI 插件）。
• 节点资源：不同 Namespace 的 Pod 可能调度到同一节点，共享内核与宿主机资源。
• 存储卷：PersistentVolume 是集群级别资源，可被不同 Namespace 的 PVC 绑定。
• 自定义资源（CRD）：CRD 定义是集群级别，但其实例可限定在 Namespace 内。

4.2 NetworkPolicy：实现网络隔离

NetworkPolicy 是 Kubernetes 原生的网络隔离机制，通过 标签选择器 定义 Pod 的入站（Ingress）和出站（Egress）规则。它需要 CNI 插件（如 Calico、Cilium、Weave Net）支持才能生效。

4.2.1 核心概念

4.2.2 典型隔离场景：禁止跨 Namespace 通信

以下策略实现：仅允许同一 Namespace 内的 Pod 互相通信，拒绝所有跨 Namespace 入站流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-ns-ingress
  namespace: tenant-a
spec:
  podSelector: {}  # 作用于本 Namespace 所有 Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: tenant-a  # 仅允许同 Namespace

4.2.3 多租户网络隔离最佳实践

• 默认拒绝所有入站/出站：为每个租户 Namespace 创建一条默认拒绝策略，再按需开放。
• 使用 Namespace 标签：为每个租户 Namespace 打上唯一标签（如 tenant: alpha），便于在策略中引用。
• 允许系统组件：确保 kube-system、监控、日志等基础设施 Namespace 的流量不被误拦。
• 审计与监控：使用网络流量日志（如 Cilium Hubble）验证策略是否生效。

4.3 ResourceQuota 与 LimitRange：实现资源隔离

资源隔离确保单个租户不会“饿死”其他租户。Kubernetes 提供两层控制：ResourceQuota（Namespace 级别总量限制）和 LimitRange（Pod/容器级别默认值与边界限制）。

4.3.1 ResourceQuota：Namespace 资源天花板

ResourceQuota 限制 Namespace 内所有 Pod 的资源总和上限。常用配置项：

示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    count/pods: "50"

4.3.2 LimitRange：Pod 级别资源约束

LimitRange 在 Namespace 内设置 Pod 或容器的资源默认值（default）和边界值（min / max）。它防止租户创建过小或过大的容器。

示例：

apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-a
spec:
  limits:
  - max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "100m"
      memory: "64Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

4.4 RBAC：实现权限隔离

RBAC（基于角色的访问控制）是 Kubernetes 权限隔离的核心。通过 Role / ClusterRole 定义权限集合，再通过 RoleBinding / ClusterRoleBinding 将角色绑定到用户、组或 ServiceAccount。

4.4.1 核心对象

4.4.2 多租户 RBAC 设计模式

典型的多租户权限模型：

• 租户管理员：拥有所在 Namespace 的完整管理权限（admin ClusterRole 绑定到 Namespace）。
• 租户开发者：拥有 Pod、Service、Deployment 等资源的读写权限（edit ClusterRole）。
• 租户只读用户：仅能查看资源（view ClusterRole）。
• 平台管理员：通过 ClusterRoleBinding 拥有集群级别管理权限。

示例：为租户 A 的开发者创建 RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-tenant-a-binding
  namespace: tenant-a
subjects:
- kind: User
  name: dev-alice@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

4.4.3 权限隔离最佳实践

• 最小权限原则：只授予租户完成工作所需的最小权限集。
• 使用 ServiceAccount：为应用 Pod 分配专用 ServiceAccount，而非使用用户身份。
• 避免 ClusterRoleBinding 滥用：尽量使用 RoleBinding 将 ClusterRole 限定到特定 Namespace。
• 定期审计：使用 kubectl auth can-i --list --as=system:serviceaccount:ns:sa-name 验证权限。

4.5 四种隔离机制对比总结