1. 多租户概念与隔离需求
1.1 多租户的定义
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例或集群基础设施同时为多个独立用户群体（租户）提供服务，且每个租户在逻辑上彼此隔离。在云原生与 Kubernetes 语境下，多租户意味着多个团队、项目或客户共享同一套 Kubernetes 集群，但各自拥有独立的资源配额、访问权限、网络策略和存储空间。
核心特征： 共享基础设施 + 逻辑隔离 + 租户自治。
1.2 为什么需要隔离
缺乏隔离的多租户环境会引发以下风险，直接威胁集群稳定性与数据安全：
- 资源争抢（Noisy Neighbor）： 一个租户的突发负载耗尽 CPU/内存，导致其他租户应用响应变慢甚至 OOMKill。
- 安全穿透： 恶意租户利用容器逃逸或 RBAC 配置漏洞，访问其他租户的敏感数据。
- 网络干扰： 租户间未隔离的 Pod 可能通过 IP 扫描、ARP 欺骗等方式相互攻击。
- 运维混乱： 租户 A 误删 Namespace 导致租户 B 的服务中断；日志、监控指标混杂无法区分归属。
- 合规失效： 金融、医疗等场景要求租户数据物理或逻辑隔离，否则违反 GDPR、HIPAA 等法规。
关键认知： 隔离不是“一刀切”的完全独立部署，而是在共享效率与安全边界之间寻找平衡。过度隔离会丧失多租户的资源复用优势，隔离不足则引入不可控风险。
1.3 隔离的四个核心维度
Kubernetes 多租户隔离需要从计算、网络、存储、身份四个维度分别设计策略。下表总结了每个维度的隔离目标与常用技术手段：
| 维度 | 隔离目标 | Kubernetes 原生机制 | 进阶/生态工具 |
|---|---|---|---|
| 计算 | 防止租户间资源争抢，保障 QoS | ResourceQuota、LimitRange、PriorityClass | Volcano、Yunikorn（调度隔离） |
| 网络 | 禁止租户间非授权通信，防止网络攻击 | NetworkPolicy、Service 隔离 | Calico、Cilium（网络策略 + 加密） |
| 存储 | 确保租户数据不被其他租户读取或篡改 | PVC 命名空间隔离、StorageClass 限制 | CSI 卷加密、Velero（备份隔离） |
| 身份 | 控制租户对集群资源的访问权限 | RBAC、ServiceAccount、Namespace | OIDC、Kyverno（策略引擎） |
1.4 隔离维度关系图
下图展示了四个隔离维度在 Kubernetes 集群中的协同关系：计算与存储提供资源边界，网络控制通信路径，身份定义访问主体。四者共同构成多租户隔离的完整防线。
1.5 隔离策略选择矩阵
实际项目中，不同租户类型对隔离强度的需求差异很大。以下矩阵帮助架构师根据租户特征选择隔离级别：
| 租户类型 | 计算隔离 | 网络隔离 | 存储隔离 | 身份隔离 | 推荐模式 |
|---|---|---|---|---|---|
| 内部开发团队 | ResourceQuota | 默认拒绝 + 白名单 | PVC 命名空间隔离 | RBAC + 组 | 软多租户（Namespace） |
| 测试/预发环境 | LimitRange + 优先级 | NetworkPolicy 严格 | StorageClass 限制 | ServiceAccount 绑定 | 软多租户 + 策略增强 |
| 外部客户（SaaS） | 节点/内核级隔离 | CNI 加密隧道 | CSI 卷加密 | OIDC + 审计 | 硬多租户（虚拟集群） |
| 金融/合规场景 | 专用节点池 + 内核隔离 | 完全隔离 + 审计日志 | 加密 + 独立存储后端 | 多因素 + 细粒度 RBAC | 物理/虚拟集群隔离 |
架构建议： 从“软多租户”起步（基于 Namespace + RBAC + ResourceQuota），随着安全需求升级逐步引入 NetworkPolicy、加密存储、节点隔离等硬隔离手段。避免一开始就过度设计，导致运维复杂度失控。