1. 多租户隔离概述
1.1 多租户概念
多租户（Multi-Tenancy）是一种软件架构模式，指单个平台实例同时服务多个独立用户群体（租户），每个租户在逻辑上彼此隔离。在 Kubernetes 语境下，租户可以是一个团队、一个项目、一个业务线或一个外部客户，共享同一套集群资源，但互不感知、互不干扰。
核心特征： 资源共享 + 逻辑隔离 + 安全边界 + 可计量
| 维度 | 单租户集群 | 多租户集群 |
|---|---|---|
| 资源利用率 | 低，每个集群独立预留峰值容量 | 高，租户间错峰复用 |
| 运维成本 | 高，每租户一套控制面 | 低，共享控制面与节点池 |
| 安全边界 | 物理/虚拟化硬隔离 | 依赖 RBAC、NetworkPolicy、PodSecurity |
| 故障爆炸半径 | 小，隔离在单集群内 | 大，需严格限流与配额 |
1.2 Kubernetes 多租户挑战
Kubernetes 原生设计并未内置“租户”概念，实现多租户面临以下核心挑战：
- 身份与权限碎片化： 仅靠 Namespace + RBAC 难以表达跨 Namespace 的租户边界，ServiceAccount 与用户映射关系复杂。
- 网络策略覆盖不足： 默认 Pod 间全通，NetworkPolicy 需逐 Namespace 配置，租户间 east-west 流量管控易遗漏。
- 资源竞争与噪声干扰： 缺少租户级 ResourceQuota 聚合，一个租户的突发流量可能挤占其他租户的节点资源。
- 审计与计量粒度粗： 原生 Audit Log 不携带租户标签，成本分摊需额外打标与聚合。
- 控制面共享风险： etcd、API Server、Controller Manager 为所有租户共用，恶意请求或异常 Pod 可能影响控制面稳定性。
常见误区： 仅靠 Namespace 隔离就认为实现了多租户。Namespace 只是逻辑分组，不具备安全隔离能力，Pod 仍可跨 Namespace 访问 Service 或直接通过 IP 通信。
1.3 隔离模型：软隔离 vs 硬隔离
根据安全等级与资源隔离程度，Kubernetes 多租户分为两种主流模型：
| 对比维度 | 软隔离（Soft Multi-Tenancy） | 硬隔离（Hard Multi-Tenancy） |
|---|---|---|
| 控制面 | 共享同一套 API Server / etcd | 每个租户独立控制面（虚拟集群或物理集群） |
| 数据面 | 共享节点池，通过 cgroup / quota 限制 | 专用节点池或独立节点（节点级隔离） |
| 网络隔离 | NetworkPolicy + 服务网格 mTLS | 独立 CNI 插件或 VPC 子网 |
| 安全等级 | 中等，适合内部团队/开发测试 | 高，适合金融、医疗、外部客户 |
| 资源开销 | 低，复用率高 | 高，每租户预留控制面与节点 |
| 典型工具 | vcluster、Capsule、Kiosk | Cluster API + 独立集群、虚拟节点 |
1.4 课程目标与收益
本课程旨在帮助学员从零构建一套可生产落地的多租户隔离集群，并具备容量预测与压测验证能力。具体目标与收益如下：
| 目标领域 | 具体目标 | 学员收益 |
|---|---|---|
| 隔离架构设计 | 掌握软隔离与硬隔离的选型与实现 | 能根据业务安全等级设计租户隔离方案 |
| 模板蓝图构建 | 产出可复用的多租户集群模板（Helm + Kustomize） | 新租户上线时间从周级缩短到小时级 |
| 压测沙盘搭建 | 部署 Locust / K6 + Prometheus + Grafana 压测环境 | 具备租户级性能基准与瓶颈定位能力 |
| 容量预测模型 | 基于历史指标训练线性回归/时序预测模型 | 提前 2-4 周预警资源不足，降低 OOM 与调度失败 |
| 生产级安全加固 | 集成 OPA/Gatekeeper、Kyverno、Pod Security Standards | 满足 SOC2 / PCI-DSS 合规要求 |
课程特色： 每章均附带可运行的代码仓库与沙盘环境，学员可在本地 Kind 集群或云上 EKS 中直接演练，所有模板与脚本均开源。