1. 多租户概念与背景
1.1 多租户的定义
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时为多个独立的租户（Tenant）提供服务，且每个租户在逻辑上彼此隔离。租户可以是一个组织、一个团队、一个项目或一个客户，具体取决于业务场景。
在云原生与 Kubernetes 语境下，多租户意味着共享同一套控制平面与数据平面资源，但每个租户拥有独立的命名空间、网络策略、资源配额与访问权限。租户之间互不可见，且不能干扰彼此的工作负载。
核心区分：多租户 ≠ 多实例。多实例是为每个客户部署独立的应用实例；多租户是共享同一实例，通过隔离机制实现逻辑分离。多租户的资源利用率更高，运维成本更低。
1.2 核心挑战
多租户架构面临三大核心挑战，任何一项处理不当都会导致系统不可用或数据泄露。
| 挑战维度 | 定义 | 典型风险 | Kubernetes 对应措施 |
|---|---|---|---|
| 隔离性 | 租户之间的资源、数据、网络、存储必须严格分离 | 租户 A 误删租户 B 的 Pod；租户 A 读取租户 B 的 ConfigMap | Namespace + NetworkPolicy + RBAC + ResourceQuota |
| 安全性 | 防止租户越权访问、数据泄露、恶意攻击 | 容器逃逸到宿主机；Pod 访问其他租户的 Service | PodSecurityPolicy / OPA / Kyverno + 服务网格 mTLS |
| 资源公平性 | 确保单个租户不会抢占或耗尽集群公共资源 | 租户 A 突发流量占满所有 Node CPU，导致租户 B 无法调度 | ResourceQuota + LimitRange + PriorityClass + 动态调度策略 |
常见误区：仅靠 Kubernetes Namespace 无法实现真正的多租户隔离。Namespace 只是逻辑分组，默认不提供网络隔离、资源硬限制或跨 Namespace 的访问控制。必须组合使用 NetworkPolicy、RBAC、ResourceQuota 和 Admission Controller 才能构建生产级多租户环境。
1.3 典型应用场景
多租户架构在以下两类场景中最为常见，其隔离需求与实现路径各有侧重。
场景一：SaaS 平台
- 业务形态：云服务商为多个企业客户提供同一套应用（如 CRM、ERP、数据分析平台）。
- 隔离要求：数据隔离级别最高，通常要求租户数据完全不可交叉访问；部分合规场景（金融、医疗）甚至要求物理隔离。
- 典型架构：每个租户独占一个 Namespace + 独立数据库 Schema / 独立数据库实例 + 网络策略禁止跨 Namespace 通信。
- 资源分配：按租户付费等级分配 Guaranteed QoS 的 Pod，使用 PriorityClass 保障高等级租户的调度优先级。
场景二：企业内部 DevOps 平台
- 业务形态：企业内多个业务线、项目组共享同一套 Kubernetes 集群，各自部署微服务。
- 隔离要求：以团队隔离为主，允许有限度的跨团队协作（如共享中间件、日志中心）。
- 典型架构：每个团队一个 Namespace + 共享 Ingress Controller + 统一监控与日志采集；通过 RBAC 控制团队 Leader 只能管理本 Namespace。
- 资源分配：使用 ResourceQuota 限制每个团队的 CPU/内存上限，避免某个团队的无节制部署影响集群稳定性。
关键对比：SaaS 平台更关注数据安全与合规，企业内部 DevOps 更关注资源公平与运维效率。两种场景的隔离粒度、网络策略、资源配额策略差异显著，在设计控制平面资源模型时必须区分对待。
1.4 多租户隔离层次模型
下图展示了从软隔离到硬隔离的完整层次，以及每个层次对应的 Kubernetes 原生机制。实际生产环境通常根据租户等级混合使用多个层次。
1.5 多租户隔离策略对比
下表从隔离强度、运维复杂度、资源利用率、成本四个维度对比三种主流多租户策略，帮助架构师在方案选型时做出权衡。
| 策略 | 隔离强度 | 运维复杂度 | 资源利用率 | 成本 | 典型场景 |
|---|---|---|---|---|---|
| 软多租户 （共享集群 + Namespace） |
低 | 低 | 高 | 低 | 内部开发测试、低安全需求 DevOps |
| 硬多租户 （共享集群 + 强隔离策略） |
中 | 中 | 中 | 中 | SaaS 平台、多团队生产环境 |
| 物理多租户 （独立集群 / 独立 Node） |
高 | 高 | 低 | 高 | 金融、医疗、政府合规场景 |