1. K8s 多租户概述
1.1 多租户概念
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够为多个独立的用户群体（租户）提供服务，同时确保每个租户的数据、配置、资源与操作彼此隔离。在 Kubernetes 语境下，租户通常对应一个团队、一个项目、一个业务线或一个客户，每个租户拥有独立的命名空间、资源配额、网络策略与访问权限。
核心目标：在共享集群资源的前提下，实现租户之间的安全隔离、资源公平调度与运维自治，避免“吵闹邻居”效应与越权访问。
1.2 K8s 原生多租户模型
Kubernetes 本身并未提供“租户”这一原生 API 对象，而是通过以下原语组合构建多租户能力：
| 原语 | 隔离维度 | 说明 |
|---|---|---|
| Namespace | 资源命名空间 | 逻辑隔离，资源名称在命名空间内唯一 |
| RBAC | 访问控制 | 基于 Role/ClusterRole + Binding 控制用户对资源的操作权限 |
| NetworkPolicy | 网络隔离 | 基于标签选择器控制 Pod 间、命名空间间的流量 |
| ResourceQuota | 资源配额 | 限制命名空间内 CPU、内存、存储、对象数量的上限 |
| LimitRange | 资源默认/限制 | 为命名空间内 Pod/Container 设置默认资源请求与限制 |
| PodSecurityPolicy / PSA | 安全上下文 | 控制 Pod 的安全敏感属性（特权、Capabilities、SELinux 等） |
这些原语共同构成了 K8s 的软多租户模型——租户之间通过命名空间隔离，但共享同一个控制平面与节点池。对于需要更强隔离的场景（如金融、医疗），通常需要引入硬多租户方案，例如虚拟节点（Virtual Kubelet）、多集群联邦或安全容器（Kata Containers）。
1.3 多租户隔离的挑战与目标
核心挑战
- 安全隔离不足：共享内核的容器（如 runc）存在逃逸风险；RBAC 配置不当可能导致跨命名空间越权。
- 资源竞争与吵闹邻居：未设置 ResourceQuota 或 LimitRange 时，一个租户的突发流量可能耗尽节点资源，影响其他租户。
- 网络与数据泄露：默认情况下 Pod 间网络互通，未配置 NetworkPolicy 时租户间可互相访问。
- 运维复杂度：租户数量增长后，RBAC 规则、网络策略、配额管理的维护成本呈指数级上升。
- 审计与合规：多租户场景下需要记录每个租户的操作行为，但原生 K8s 审计日志缺乏租户维度的聚合视图。
隔离目标
| 隔离维度 | 目标描述 | K8s 实现手段 |
|---|---|---|
| 身份与访问 | 租户只能操作自己的资源 | RBAC + ServiceAccount + OIDC 集成 |
| 网络 | 租户间默认不可达，仅允许显式开放 | NetworkPolicy + CNI 插件（Calico/Cilium） |
| 计算与存储 | 租户资源配额独立，互不抢占 | ResourceQuota + LimitRange + PriorityClass |
| 数据 | 租户数据（ConfigMap/Secret/PVC）不可跨命名空间访问 | 命名空间隔离 + RBAC + 加密存储 |
| 安全上下文 | 限制特权容器、主机路径挂载等危险操作 | Pod Security Admission (PSA) / OPA Gatekeeper |
| 审计与可观测 | 每个租户的操作可追溯、可计量 | 审计日志 + 标签聚合 + 租户级监控 |
关键原则：多租户隔离不是“全有或全无”的二元选择，而是一个分层决策。团队应根据合规要求、威胁模型与运维成本，在软隔离（命名空间 + RBAC + NetworkPolicy）与硬隔离（多集群 / 安全容器 / 虚拟节点）之间选择适当的隔离级别。
常见误区：不要认为创建了多个 Namespace 就等于实现了多租户隔离。缺少 RBAC 约束、NetworkPolicy 默认放行、未设置 ResourceQuota 的 Namespace 本质上只是“逻辑分组”，无法阻止租户间的越权访问与资源抢占。真正的多租户隔离需要组合使用上述所有原语，并配合持续的策略审计。