📚 课程目录第2章 Kubernetes原生隔离机制

2. Kubernetes 原生隔离机制

Kubernetes 本身提供了四层基础隔离能力，它们是构建多租户 Operator 的基石。Operator 在管理租户资源时，必须依赖并复核这些机制是否被正确配置。本章逐一拆解命名空间隔离、RBAC 权限控制、NetworkPolicy 网络隔离和 ResourceQuota 资源限制。

2.1 命名空间隔离：逻辑边界

命名空间（Namespace）是 Kubernetes 中最基础的隔离单元。它将集群内的资源划分为逻辑组，每个租户拥有独立的命名空间，从而避免资源名称冲突，并为后续的权限、网络、配额策略提供作用域。

  关键认知： 命名空间只提供逻辑隔离，不提供安全隔离。默认情况下，不同命名空间的 Pod 仍可通过网络互通，且共享同一套节点资源。真正的安全隔离需要结合 RBAC 和 NetworkPolicy。

Operator 复核要点： 检查每个租户是否拥有独立的命名空间，且命名空间名称是否遵循统一的命名规范（如 tenant-{id}）。避免多个租户共享同一命名空间。

2.2 RBAC 权限控制：谁可以做什么

基于角色的访问控制（RBAC）是 Kubernetes 授权的主要方式。Operator 需要为每个租户创建独立的 ServiceAccount，并通过 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding 精确控制其对命名空间内资源的操作权限。

RBAC 对象	作用域	用途	Operator 复核要点
ServiceAccount	命名空间	为 Pod 或用户提供身份标识	每个租户是否拥有独立的 ServiceAccount
Role	命名空间	定义对特定命名空间内资源的操作权限	权限是否遵循最小权限原则
ClusterRole	集群	定义集群级别资源（如 Node、PV）的权限	是否误授予了集群级别的敏感权限
RoleBinding	命名空间	将 Role 绑定到 ServiceAccount 或用户	绑定关系是否与租户对应
ClusterRoleBinding	集群	将 ClusterRole 绑定到全局主体	是否被用于绕过命名空间隔离

常见风险： Operator 在创建租户时，如果直接使用 ClusterRoleBinding 将 ClusterRole 绑定到租户的 ServiceAccount，会导致该租户获得跨命名空间的访问能力，破坏隔离性。必须优先使用 Role + RoleBinding。

2.3 NetworkPolicy 网络隔离

默认情况下，Kubernetes 集群内的所有 Pod 都可以互相通信。NetworkPolicy 是一种以应用为中心的网络隔离机制，通过定义入站（Ingress）和出站（Egress）规则，控制 Pod 组之间的流量。

实现 NetworkPolicy 需要集群中安装支持的网络插件（如 Calico、Cilium、Weave Net 等）。如果插件不支持，NetworkPolicy 将不会生效。

  Operator 复核要点：
  检查每个租户命名空间是否至少有一条默认拒绝所有入站流量的 NetworkPolicy。
检查是否显式允许了必要的跨租户通信（如监控系统、DNS 解析）。
确认网络插件已启用并支持 NetworkPolicy。

2.4 ResourceQuota 资源限制

ResourceQuota 用于限制命名空间级别的资源使用总量，包括 CPU、内存、存储卷数量、Pod 数量、Service 数量等。这是防止单个租户耗尽集群资源的关键机制。

一个典型的 ResourceQuota 配置示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-001
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"
    services: "10"
    configmaps: "10"
    secrets: "10"

Operator 复核要点：

检查每个租户命名空间是否都配置了 ResourceQuota。
检查配额值是否合理，是否与租户的 SLA 匹配。
检查是否配置了 LimitRange，为未显式设置资源请求/限制的 Pod 提供默认值，避免 ResourceQuota 因缺少请求值而拒绝调度。

2.5 四层隔离机制对比

隔离维度	核心对象	隔离范围	Operator 复核重点	绕过风险
命名空间	Namespace	资源名称、作用域	命名空间唯一性、命名规范	低（仅逻辑隔离）
RBAC	Role / RoleBinding	API 操作权限	最小权限、避免 ClusterRoleBinding	中（权限配置错误）
NetworkPolicy	NetworkPolicy	网络流量	默认拒绝策略、必要白名单	高（插件不支持或未配置）
ResourceQuota	ResourceQuota / LimitRange	资源使用量	配额值、默认限制	中（未配置 LimitRange 导致 Pod 被拒绝）

Operator 开发提醒： 在编写 Operator 的租户创建逻辑时，必须将这四层隔离机制作为原子操作一起创建。如果只创建命名空间而遗漏了 RBAC 或 NetworkPolicy，租户隔离将形同虚设。建议在 Operator 的 Reconcile 循环中增加复核逻辑，定期检查这些资源是否存在且配置正确。