3. 租户隔离基础概念
在 Kubernetes 多租户集群中，租户隔离是保障安全性与资源公平性的基石。本章围绕四个核心维度展开：Namespace 隔离、RBAC 权限模型、NetworkPolicy 网络隔离以及ResourceQuota 与 LimitRange。理解这些基础概念，是后续设计租户隔离蓝图与回归报告的前提。
3.1 Namespace 隔离：逻辑边界
Namespace 是 Kubernetes 实现多租户隔离的第一层逻辑边界。它将集群内的资源划分为虚拟子集群，不同 Namespace 中的资源（如 Pod、Service、ConfigMap）彼此不可见，除非显式配置跨 Namespace 访问。
| 特性 | 说明 | 典型场景 |
|---|---|---|
| 资源隔离 | 同名资源可在不同 Namespace 共存 | 开发/测试/生产环境隔离 |
| 默认策略 | Pod 默认只能访问同 Namespace 的 Service | 微服务内部通信 |
| 配额绑定 | ResourceQuota 必须绑定到特定 Namespace | 租户资源上限控制 |
| 生命周期 | 删除 Namespace 会级联删除其下所有资源 | 租户退租清理 |
{tenant}-{env} 格式，例如 team-a-prod、team-b-dev，便于审计与自动化管理。
3.2 RBAC 权限模型：细粒度授权
RBAC（基于角色的访问控制）是 Kubernetes 默认的授权机制。它通过 Role / ClusterRole 定义权限集合，再通过 RoleBinding / ClusterRoleBinding 将角色绑定到用户或 ServiceAccount，实现“谁能在哪个 Namespace 做什么”的精细控制。
- Role：命名空间级别权限，仅作用于指定 Namespace。
- ClusterRole：集群级别权限，可跨 Namespace 或作用于集群资源（如 Node、PV）。
- RoleBinding：将 Role 绑定到主体（User/Group/SA），作用域为同一 Namespace。
- ClusterRoleBinding：将 ClusterRole 绑定到主体，作用域为整个集群。
以下是一个典型的租户只读权限配置示例：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-a-prod
name: tenant-reader
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: team-a-prod
name: tenant-reader-binding
subjects:
- kind: User
name: alice@example.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: tenant-reader
apiGroup: rbac.authorization.k8s.io3.3 NetworkPolicy 网络隔离：微隔离防线
NetworkPolicy 是 Kubernetes 实现 Pod 级网络访问控制的资源对象。它基于 标签选择器 定义入站（Ingress）和出站（Egress）规则，默认情况下 Pod 之间允许所有流量，一旦应用 NetworkPolicy，未显式允许的流量将被拒绝。
| 策略类型 | 控制方向 | 常用选择器 |
|---|---|---|
| Ingress | 入站流量 | podSelector, namespaceSelector, ipBlock |
| Egress | 出站流量 | podSelector, namespaceSelector, ipBlock |
以下是一个隔离租户命名空间内所有 Pod 的默认拒绝策略：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: team-a-prod
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress3.4 ResourceQuota 与 LimitRange：资源公平性保障
ResourceQuota 和 LimitRange 是 Kubernetes 提供的资源管理机制，确保多租户环境下不会出现“资源抢占”问题。
3.4.1 ResourceQuota：硬性配额上限
ResourceQuota 为 Namespace 设置资源使用上限，包括 CPU、内存、存储以及对象数量（如 Pod、Service、PVC 等）。一旦配额耗尽，后续创建请求将被拒绝。
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-quota
namespace: team-a-prod
spec:
hard:
requests.cpu: "4"
requests.memory: "8Gi"
limits.cpu: "8"
limits.memory: "16Gi"
persistentvolumeclaims: "10"
pods: "50"
services: "20"3.4.2 LimitRange：默认资源限制与范围
LimitRange 在 Namespace 级别设置 Pod 或容器的默认资源请求/限制，以及最小/最大约束。它确保未显式设置资源限制的 Pod 不会无限占用集群资源。
apiVersion: v1
kind: LimitRange
metadata:
name: tenant-limits
namespace: team-a-prod
spec:
limits:
- max:
cpu: "2"
memory: "4Gi"
min:
cpu: "100m"
memory: "128Mi"
default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "200m"
memory: "256Mi"
type: Container| 维度 | ResourceQuota | LimitRange |
|---|---|---|
| 作用范围 | Namespace 整体 | 单个 Pod / Container |
| 主要功能 | 设置资源使用上限 | 设置默认值及最小/最大约束 |
| 触发时机 | 资源创建时检查配额 | Pod 创建时注入默认值 |
| 典型用途 | 防止租户超用集群资源 | 防止未设置资源限制的 Pod 运行 |
3.5 四层隔离的依赖关系与回归测试要点
在实际的租户隔离蓝图中，四层机制需要协同工作，任何一层的缺失或配置错误都可能导致隔离失效。回归报告设计时应重点关注以下核验点：
- Namespace 存在性：确认目标 Namespace 已创建且标签正确。
- RBAC 绑定完整性：验证每个租户的 RoleBinding 是否覆盖所有必要权限，且无越权。
- NetworkPolicy 生效性：通过
kubectl exec或 Conformance Test 验证跨 Namespace 访问是否被正确阻断。 - 配额一致性：ResourceQuota 的
hard值与 LimitRange 的max/min不应冲突，避免 Pod 永远无法创建。