1. 多租户隔离概述
1.1 多租户概念
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时服务多个独立用户群体（即“租户”），并为每个租户提供逻辑或物理上的隔离环境。在 Kubernetes 语境下，租户通常对应一个团队、一个项目、一个业务线或一个客户。
核心目标：在共享集群资源的前提下，确保租户之间互不感知、互不干扰，同时满足安全性、资源公平性和运维可管理性。
多租户隔离的三大维度：
| 隔离维度 | 说明 | Kubernetes 实现手段 |
|---|---|---|
| 身份与访问隔离 | 租户只能访问自己的资源，不能越权操作其他租户的资源 | RBAC、ServiceAccount、Namespace 级别的 RoleBinding |
| 网络隔离 | 租户之间的 Pod 默认不能互相通信，或仅允许特定策略下的通信 | NetworkPolicy、CNI 插件（Calico/Cilium） |
| 资源配额隔离 | 每个租户的资源使用上限受控，防止“吵闹邻居”耗尽集群资源 | ResourceQuota、LimitRange、PriorityClass |
1.2 Kubernetes 多租户模型
Kubernetes 社区将多租户模型分为三种成熟度级别，实际生产环境通常混合使用：
- 软多租户（Soft Multi-Tenancy）：租户共享同一个控制平面，通过 Namespace 和 RBAC 实现逻辑隔离。适用于内部团队、Dev/Test 环境。
- 硬多租户（Hard Multi-Tenancy）：租户之间使用独立的控制平面或虚拟集群（如 vCluster、Kiosk），甚至使用独立的 Kubernetes 集群。适用于外部客户、生产环境。
- 混合多租户：在共享集群基础上，对高安全需求的租户使用节点级隔离（NodeSelector、Taint/Toleration）或 Pod 安全策略（Pod Security Admission）。
实践建议：大多数企业从“软多租户”起步，以 Namespace 作为租户边界，配合 ResourceQuota 和 NetworkPolicy 实现基础隔离。当租户数量超过 50 个或安全合规要求升级时，再考虑引入硬多租户方案。
1.3 命名空间隔离原理
Namespace 是 Kubernetes 实现多租户隔离的基石。每个 Namespace 在逻辑上是一个独立的虚拟集群，资源名称在同一个 Namespace 内唯一，跨 Namespace 可以重名。
Namespace 提供的隔离能力：
- 资源对象隔离：Pod、Service、Deployment、ConfigMap、Secret 等资源默认只属于一个 Namespace，无法跨 Namespace 直接访问。
- 资源配额隔离：通过 ResourceQuota 对象为每个 Namespace 设置 CPU、内存、存储、对象数量等上限。
- 权限隔离：RBAC 的 Role 和 RoleBinding 作用域限定在单个 Namespace 内，ClusterRole 和 ClusterRoleBinding 才作用于全局。
- 网络隔离：配合 NetworkPolicy 可以控制 Namespace 内或跨 Namespace 的 Pod 通信规则。
注意：Namespace 不是完全的安全边界。某些集群范围资源（如 Node、PersistentVolume、ClusterRole）不受 Namespace 限制；Pod 默认可以通过 DNS 跨 Namespace 访问 Service（格式：<service>.<namespace>.svc.cluster.local），需要 NetworkPolicy 显式阻断。
1.4 多租户隔离的常见挑战
在实际生产环境中，多租户隔离并非“创建 Namespace + 设置 ResourceQuota”就能一劳永逸。以下是常见挑战：
| 挑战 | 表现 | 影响 |
|---|---|---|
| 配额冲突 | 多个租户的 ResourceQuota 总和超过集群容量，或租户间争抢未预留资源 | Pod 调度失败、服务质量下降 |
| 资源碎片化 | 每个 Namespace 设置了固定配额，但实际使用率不均，导致集群整体利用率低 | 资源浪费、扩容成本增加 |
| 配额覆盖遗漏 | 部分 Namespace 未设置 ResourceQuota，导致“无限制”租户占用大量资源 | 影响其他租户的正常运行 |
| 动态扩缩容冲突 | HPA 自动扩容时，Pod 数量超过 Namespace 的 ResourceQuota 上限 | 扩容失败、业务受损 |