1. 多租户 K8s 概述
1.1 多租户概念
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够为多个独立的用户群体（租户）提供服务，同时确保各租户之间的数据、配置、资源和性能相互隔离。在 Kubernetes 语境下，租户通常对应一个团队、项目、业务线或客户，每个租户拥有自己独立的命名空间、RBAC 权限、网络策略和资源配额。
核心目标：在共享集群基础设施的前提下，为每个租户提供“仿佛独占集群”的使用体验，同时降低运维成本和资源碎片。
1.2 租户隔离模型：软隔离 vs 硬隔离
Kubernetes 多租户隔离模型主要分为两类，其核心差异在于安全边界强度和资源共享程度。下表从多个维度对比两种模型：
| 对比维度 | 软隔离（Soft Multi-Tenancy） | 硬隔离（Hard Multi-Tenancy） |
|---|---|---|
| 隔离粒度 | 命名空间 + RBAC + NetworkPolicy | 独立节点 / 虚拟机 / 安全容器 |
| 安全边界 | Kubernetes API 层逻辑隔离 | 内核级 / 硬件级物理隔离 |
| 资源共享 | 共享控制面、共享节点、共享网络 | 独占节点或独占内核资源 |
| Pod 逃逸风险 | 较高（共享内核） | 较低（gVisor / Kata Containers） |
| 资源超卖 | 支持，利用率高 | 不支持或受限，利用率较低 |
| 运维复杂度 | 较低，原生 K8s 机制即可 | 较高，需额外运行时或节点管理 |
| 典型场景 | 内部开发环境、测试环境 | 金融、医疗、合规敏感生产环境 |
关键选择依据：如果租户之间互不信任且存在严格合规要求，优先选择硬隔离；如果追求资源利用率和运维效率，且租户属于同一组织内部，软隔离通常足够。
下图展示了两种隔离模型在集群中的架构差异：
1.3 多租户在 K8s 中的挑战
在 Kubernetes 中实现多租户并非简单的命名空间划分，平台团队需要面对以下六大核心挑战：
- 安全隔离不足：共享内核意味着 Pod 逃逸可能影响其他租户；RBAC 配置错误可能导致越权访问。
- 资源争抢与噪声邻居：缺乏有效的资源配额和优先级控制时，一个租户的突发流量可能挤占其他租户的 CPU/内存/网络带宽。
- 网络策略管理复杂：大规模集群中，NetworkPolicy 规则数量激增，维护和审计成本高，且容易遗漏导致隔离失效。
- Pod 安全标准（PSS）落地困难：不同租户对 Pod 安全上下文要求不同（如特权容器、hostPath 挂载），统一基线难以兼顾灵活性与安全性。
- 审计与合规追溯：多租户环境下，需要精确记录每个租户的操作行为，但 Kubernetes 原生审计日志缺乏租户维度的聚合视图。
- 运维与成本分摊：共享集群中，如何公平计量各租户的资源消耗并进行成本分摊，是组织级治理的常见痛点。
常见误区：不要认为“只要给每个团队一个 Namespace 就完成了多租户”。缺少 Pod 安全策略、网络策略和资源配额的多租户，本质上只是“多命名空间”，而非真正的多租户隔离。
下图总结了多租户面临的挑战及其影响范围：
1.4 本章小结
多租户是 Kubernetes 生产化进程中不可回避的课题。理解软隔离与硬隔离的适用场景，以及安全、资源、网络、策略、审计、成本六大挑战，是后续学习 Pod 安全策略与准入控制配置的基础。在接下来的章节中，我们将逐一深入这些挑战的解决方案。