1. 多租户隔离概述
1.1 多租户概念
多租户（Multi-Tenancy）是指单个 Kubernetes 集群同时服务于多个独立用户群体（租户）的架构模式。每个租户在逻辑上拥有自己的命名空间、资源配额、网络策略和访问权限，彼此互不干扰。多租户隔离的核心目标是：安全、资源公平、运维自治。
关键定义： 租户 ≠ 团队。租户可以是业务部门、项目组、外部客户或环境（开发/测试/生产）。隔离粒度取决于组织架构和合规要求。
1.2 隔离模型：软隔离 vs 硬隔离
根据隔离的严格程度和实现方式，多租户隔离分为两种主流模型：
| 对比维度 | 软隔离（Soft Multi-Tenancy） | 硬隔离（Hard Multi-Tenancy） |
|---|---|---|
| 实现层 | Kubernetes 原生资源（Namespace、RBAC、NetworkPolicy、ResourceQuota） | 虚拟化节点、安全容器（Kata Containers）、Sidecar 代理、CNI 隔离 |
| 安全边界 | 逻辑隔离，共享宿主机内核 | 物理或虚拟化隔离，独立内核 |
| 性能开销 | 低，几乎无额外损耗 | 中高，取决于虚拟化或安全容器方案 |
| 运维复杂度 | 低，原生 API 即可管理 | 高，需额外组件（如 Kata、gVisor、Cilium） |
| 适用场景 | 内部团队、开发/测试环境、信任度较高的租户 | 外部客户、金融/合规场景、高安全要求 |
| 逃逸风险 | 存在容器逃逸风险 | 逃逸风险极低 |
选型建议： 大多数企业从软隔离起步，随着安全合规要求提升，逐步在关键租户上引入硬隔离。本课程以软隔离为基础，重点讲解 NetworkPolicy 在软隔离模型中的故障排查。
1.3 Kubernetes 原生隔离机制简介
Kubernetes 提供了四层原生隔离机制，构成多租户隔离的基础骨架：
- 命名空间（Namespace）： 逻辑分区，隔离资源名称、配额和默认网络策略范围。
- 基于角色的访问控制（RBAC）： 通过 Role/ClusterRole + RoleBinding/ClusterRoleBinding 控制租户对 API 资源的操作权限。
- 资源配额（ResourceQuota）与限制范围（LimitRange）： 防止单个租户耗尽集群资源，保障公平调度。
- 网络策略（NetworkPolicy）： 控制 Pod 之间、Pod 与外部之间的流量，是网络隔离的核心手段。
常见误区： 仅创建 Namespace 不等于隔离。没有 NetworkPolicy 时，所有 Namespace 中的 Pod 默认可以互相通信（全通网络模型）。隔离必须显式声明策略。
1.4 隔离机制协同工作流程
当请求进入集群时，四层隔离机制按以下顺序协同生效：
- 认证与授权（RBAC）： 验证用户身份，检查是否有权操作目标 Namespace 的资源。
- 资源准入（ResourceQuota / LimitRange）： 在创建 Pod 或 PVC 时，检查是否超出租户配额。
- 网络隔离（NetworkPolicy）： 在数据平面，CNI 插件根据 NetworkPolicy 规则决定是否允许数据包通过。
- 运行时隔离（可选硬隔离）： 安全容器或虚拟化节点提供最后一层内核级隔离。
故障排查要点： 当租户间通信异常时，排查顺序应为：
① 检查 NetworkPolicy 是否允许目标流量（最常见原因）
② 检查 RBAC 是否限制了 ServiceAccount 的权限
③ 检查 ResourceQuota 是否导致 Pod 未成功调度
④ 检查 CNI 插件是否支持 NetworkPolicy（如 Flannel 默认不支持）
① 检查 NetworkPolicy 是否允许目标流量（最常见原因）
② 检查 RBAC 是否限制了 ServiceAccount 的权限
③ 检查 ResourceQuota 是否导致 Pod 未成功调度
④ 检查 CNI 插件是否支持 NetworkPolicy（如 Flannel 默认不支持）
1.5 本章小结
- 多租户隔离是 Kubernetes 集群治理的基础能力，软隔离适合内部场景，硬隔离适合高安全场景。
- Kubernetes 原生提供 Namespace、RBAC、ResourceQuota、NetworkPolicy 四层隔离机制。
- NetworkPolicy 是网络隔离的核心，也是故障排查的高频区域。
- 从下一章开始，我们将深入 NetworkPolicy 的语法、默认行为与常见故障模式。