1.1 多租户隔离概述
1.1.1 多租户概念
多租户（Multi-Tenancy）是指单个软件或平台实例同时服务多个独立用户群体（租户）的架构模式。在 Kubernetes 语境下，每个租户通常对应一个团队、项目、业务线或客户，共享同一套控制平面与数据平面资源，但彼此在网络、存储、计算、权限层面互不感知、互不干扰。
核心特征：逻辑隔离而非物理隔离；资源复用最大化；租户间操作边界清晰。
1.1.2 隔离必要性
缺乏隔离的多租户集群会面临以下风险：
| 风险维度 | 具体表现 | 影响等级 |
|---|---|---|
| 安全 | 恶意 Pod 逃逸后窃取其他租户数据 | 严重 |
| 性能 | 租户 A 的突发流量挤占租户 B 的 CPU/内存 | 高 |
| 稳定性 | 租户 C 的异常 Pod 导致节点 NotReady，波及全局 | 高 |
| 合规 | 审计日志混杂，无法追溯租户级操作 | 中 |
| 运维 | 误操作删除其他租户的 Namespace 或 CRD | 中 |
关键认知：隔离不是“一刀切”的物理拆分，而是根据业务风险等级选择不同隔离深度。过度隔离会降低资源利用率，不足隔离则埋下故障隐患。
1.1.3 常见隔离模型：软隔离 vs 硬隔离
Kubernetes 社区与生产实践将多租户隔离归纳为两大模型：软隔离（Soft Multi-Tenancy）与硬隔离（Hard Multi-Tenancy）。两者在资源边界、安全假设、运维复杂度上存在本质差异。
| 对比维度 | 软隔离 | 硬隔离 |
|---|---|---|
| 共享范围 | 共享控制平面 + 共享数据平面 | 共享控制平面 + 独立数据平面 |
| 租户边界 | Namespace + RBAC + NetworkPolicy | 虚拟集群（vCluster）或独立节点池 |
| 安全假设 | 租户间相互信任或低敏感 | 租户间不可信，需强隔离 |
| 资源争抢 | 依赖 ResourceQuota / LimitRange | 节点级 cgroup 或物理隔离 |
| 运维成本 | 低，原生 API 即可实现 | 高，需额外组件或集群虚拟化 |
| 典型场景 | 内部开发环境、测试集群 | 金融、医疗、SaaS 生产环境 |
选型建议：80% 的企业内部场景使用软隔离即可满足需求；只有面对强监管、多级安全域或外部客户数据隔离时，才需要引入硬隔离方案。
1.1.4 隔离模型对比架构图
下图从控制平面与数据平面两个维度，直观展示软隔离与硬隔离的架构差异：
1.1.5 隔离模型选择决策流程
在实际项目中，选择软隔离还是硬隔离需要结合业务需求、安全等级与运维能力综合判断。以下决策流程可帮助团队快速定位：
- 评估租户信任度：租户之间是否完全不可信？是 → 考虑硬隔离；否 → 软隔离即可。
- 评估合规要求：是否存在金融、医疗等强监管场景？是 → 硬隔离；否 → 继续评估。
- 评估资源利用率目标：是否要求 80% 以上节点利用率？是 → 优先软隔离 + 精细化配额；否 → 硬隔离可接受。
- 评估运维能力：团队是否有能力维护 vCluster 或独立节点池？是 → 硬隔离可行；否 → 软隔离更稳妥。
- 最终决策：综合以上因素，选择隔离模型并制定对应的资源模型与性能调优策略。
实战建议：推荐采用“软隔离为主，硬隔离兜底”的混合策略。日常开发测试使用软隔离，核心生产租户或高敏感业务单独分配硬隔离节点池，兼顾效率与安全。