2. 核心概念：租户隔离的定义、多租户模型（SaaS/PaaS）、隔离边界（网络/存储/计算）
2.1 租户隔离的定义
租户隔离（Tenant Isolation）是指在共享基础设施（计算、网络、存储）上，为不同租户（Tenant）提供逻辑或物理上完全独立的运行环境，确保一个租户的操作、数据、流量不会影响或泄露给其他租户。在集群升级场景下，隔离边界一旦被破坏，可能导致租户 A 的 Pod 被调度到租户 B 的节点、网络策略失效、存储卷挂载错乱等严重故障。
核心目标： 在共享资源池中实现“安全多租户”（Secure Multi-Tenancy），使每个租户感知不到其他租户的存在，同时保证资源利用率和运维效率。
2.2 多租户模型：SaaS vs. PaaS
不同平台形态对隔离的粒度、层级和实现方式有显著差异。下表对比了 SaaS 和 PaaS 两种典型多租户模型的关键特征：
| 维度 | SaaS 多租户模型 | PaaS 多租户模型 |
|---|---|---|
| 隔离粒度 | 应用实例 / 用户组织 | 项目 / 命名空间 / 集群 |
| 租户感知 | 应用层显式感知租户 ID | 平台层通过元数据（Label/Annotation）隐式感知 |
| 资源分配 | 按租户配额（Quota）分配 | 按命名空间（Namespace）分配 ResourceQuota |
| 网络隔离 | 应用层 / Session 隔离 | NetworkPolicy + CNI 插件（如 Calico） |
| 存储隔离 | 应用层数据分区 / Schema 隔离 | PV/PVC 绑定 + StorageClass 限制 |
| 升级影响范围 | 应用滚动升级，租户无感 | 集群升级可能导致 Namespace 级服务中断 |
| 典型场景 | CRM、ERP、企业办公套件 | Kubernetes 集群、容器平台、中间件服务 |
升级测试启示： 在集群升级场景下，PaaS 模型的隔离边界更依赖基础设施层（CNI、CSI、调度器）的正确性，升级过程中必须验证这些组件的隔离策略是否被重置或破坏。
2.3 隔离边界：网络 / 存储 / 计算
隔离边界是租户隔离的具体实现层。在 Kubernetes 集群中，三个核心边界分别对应不同的资源对象和策略：
- 网络隔离边界： 通过 NetworkPolicy 定义 Pod 之间的通信规则，结合 CNI 插件（Calico、Cilium）实现租户级网络隔离。升级时需验证 NetworkPolicy 规则是否被保留、CNI 组件是否兼容新版本。
- 存储隔离边界： 通过 PV/PVC 绑定机制确保一个租户的存储卷不能被其他租户访问。StorageClass 的 ReclaimPolicy、AccessModes 以及 CSI 驱动版本升级都可能影响隔离性。
- 计算隔离边界： 通过 ResourceQuota、LimitRange、Pod Priority/Preemption 以及节点亲和性（NodeAffinity）实现 CPU/内存资源的公平分配和硬隔离。升级后调度器行为变化可能导致资源争抢。
下图展示了集群升级前后三个隔离边界的验证要点：
2.4 隔离边界的测试验证清单
在集群升级测试中，针对三个隔离边界，需要逐项验证以下关键指标：
| 隔离边界 | 验证项 | 预期结果 | 失败影响 |
|---|---|---|---|
| 网络 | NetworkPolicy 规则完整性 | 升级后规则数量、内容与升级前一致 | 租户间非授权访问 |
| CNI 插件版本兼容性 | Pod 网络连通性正常，无丢包 | 集群网络瘫痪 | |
| 跨 Namespace 访问阻断 | 未授权流量被拒绝 | 数据泄露 | |
| 存储 | PV/PVC 绑定关系 | 升级后 PVC 仍绑定原 PV | 数据丢失或挂载失败 |
| CSI 驱动版本 | 驱动与集群版本兼容 | 存储卷无法创建/挂载 | |
| 存储卷访问权限 | 跨租户无法访问对方卷 | 数据越权 | |
| 计算 | ResourceQuota 保留 | 升级后 Quota 值不变 | 资源超卖或饥饿 |
| Pod 调度策略 | NodeAffinity/Taint 仍生效 | Pod 调度到错误节点 | |
| LimitRange 约束 | Pod 资源限制未丢失 | 单个 Pod 耗尽节点资源 |
升级风险提示： 在集群升级过程中，kube-controller-manager、kube-scheduler 等核心组件的配置可能被覆盖或重置，导致 ResourceQuota、LimitRange 等隔离策略失效。务必在升级前备份所有隔离策略配置，并在升级后执行自动化回归验证。
2.5 隔离模型在升级测试中的映射关系
为了在测试中精确验证隔离边界，需要将概念模型映射为可执行的测试用例。下表展示了从“隔离定义”到“测试断言”的转换关系：
| 隔离概念 | Kubernetes 对象 | 测试方法 | 通过标准 |
|---|---|---|---|
| 网络隔离 | NetworkPolicy | 创建测试 Pod，执行 curl 跨 Namespace 访问 | 未授权请求返回超时或拒绝 |
| 存储隔离 | PersistentVolumeClaim | 尝试从租户 B 的 Pod 挂载租户 A 的 PVC | 挂载失败或权限错误 |
| 计算隔离 | ResourceQuota | 在租户内创建超过 Quota 的 Pod | 调度失败，返回 Quota 错误 |
测试设计原则： 每个隔离边界至少设计一个“正向用例”（验证隔离生效）和一个“负向用例”（验证越权被拒绝）。升级后，负向用例的失败即代表隔离边界被破坏。