3. 租户隔离蓝图概述
在集群升级治理中，租户隔离是保障多团队、多业务共存于同一基础设施时互不干扰的核心手段。本章从架构模型、资源隔离、网络隔离、数据隔离四个维度构建完整的租户隔离蓝图，为后续跨环境迁移的风险对账提供基线。
3.1 多租户架构模型
多租户架构决定了隔离的边界与粒度。根据共享程度与安全要求，主流模型分为以下三类：
| 模型 | 共享层 | 隔离层 | 适用场景 | 升级影响面 |
|---|---|---|---|---|
| 硬隔离（Dedicated） | 无 | 独立集群 / 独立节点组 | 金融核心、合规敏感业务 | 最小，升级仅影响本租户 |
| 软隔离（Shared with Limits） | 控制面、节点池 | Namespace + ResourceQuota + NetworkPolicy | 内部开发环境、非关键业务 | 中等，需协调升级窗口 |
| 混合隔离（Hybrid） | 控制面 | 专属节点组 + 自定义准入控制 | 生产多部门、成本与安全平衡 | 可控，按节点组灰度升级 |
关键决策点： 选择模型时需评估租户间的信任等级、合规审计要求以及升级时对业务连续性的容忍度。硬隔离成本最高，但升级风险最低。
下图展示了三种架构模型在集群层面的隔离边界与共享关系：
3.2 资源隔离策略
资源隔离确保租户之间不会因资源争抢导致服务质量下降。在 Kubernetes 环境中，核心策略包括：
- ResourceQuota：限制每个租户（Namespace）的 CPU、内存、PVC 总量上限，防止单个租户耗尽集群资源。
- LimitRange：为 Pod 设置默认资源请求/限制，避免未设置资源约束的 Pod 抢占共享资源。
- PriorityClass：为关键租户设置更高优先级，确保在资源竞争时核心业务优先调度。
- 节点组（NodeGroup）与污点/容忍：通过节点标签、污点将租户工作负载绑定到专属节点组，实现物理级资源隔离。
| 策略 | 隔离粒度 | 生效层级 | 升级注意事项 |
|---|---|---|---|
| ResourceQuota | Namespace | 控制面 | 升级期间配额不丢失，但需验证 API 版本兼容性 |
| LimitRange | Pod / Container | 控制面 | 新版本可能引入默认值变化，需提前审计 |
| PriorityClass | 全局 | 控制面 | 升级后需确认优先级排序逻辑未变更 |
| 节点组 + 污点 | 节点 | 数据面 | 节点升级时需确保租户 Pod 被正确驱逐或迁移 |
实践建议： 在集群升级前，使用
kubectl describe resourcequota 和 kubectl describe limitrange 导出当前配置快照，升级后对比差异，防止策略丢失或语义变化。
3.3 网络隔离策略
网络隔离防止租户间的非法访问与数据泄露。在云原生环境中，主要依赖以下机制：
- NetworkPolicy：Kubernetes 原生网络策略，基于标签选择器控制 Pod 间、Pod 与外部服务的流量。
- CNI 插件隔离：Calico、Cilium 等 CNI 插件提供更细粒度的网络策略，支持 L3-L7 层过滤。
- Service Mesh 隔离：Istio / Linkerd 通过 mTLS 和 AuthorizationPolicy 实现服务级身份认证与访问控制。
- 节点网络隔离：通过安全组、防火墙规则限制节点间非必要端口通信。
下表总结了不同网络隔离手段的适用范围与升级风险：
| 手段 | 隔离层级 | 配置复杂度 | 升级影响 |
|---|---|---|---|
| NetworkPolicy | L3/L4 | 低 | CNI 升级可能导致策略失效，需回归测试 |
| Calico 全局策略 | L3-L7 | 中 | Calico 版本升级需验证 CRD 兼容性 |
| Istio AuthorizationPolicy | L7 | 高 | Sidecar 升级期间流量中断风险 |
| 安全组 / 防火墙 | 节点 | 低 | 节点 IP 变更需同步更新规则 |
升级风险提示： CNI 插件升级或控制面组件更新可能导致 NetworkPolicy 规则暂时失效。建议在升级前录制策略快照，并在升级后执行端到端连通性测试。
3.4 数据隔离策略
数据隔离是租户隔离中最敏感的一环，涉及持久化存储、缓存、数据库等有状态组件。常见策略包括：
- PVC 命名空间隔离：每个租户的 PersistentVolumeClaim 限定在各自 Namespace 内，通过 StorageClass 绑定独立存储后端。
- 存储配额与限速：使用 StorageClass 的
maxVolumeSize、iopsPerGB等参数限制租户存储使用量。 - 数据库实例隔离：为高安全租户提供独立数据库实例或 Schema，避免跨租户数据查询。
- 加密与密钥隔离：使用租户专属加密密钥（KMS / Vault），确保存储层数据无法被其他租户解密。
下图展示了数据隔离在存储层与数据库层的典型实现路径：
升级对账要点： 在跨环境迁移或集群升级时，需逐项核对数据隔离策略是否被继承：
1. StorageClass 名称与参数是否一致；
2. 加密密钥是否已迁移或重新绑定；
3. 数据库连接字符串与访问凭证是否更新；
4. 存储配额与限速配置是否丢失。
1. StorageClass 名称与参数是否一致；
2. 加密密钥是否已迁移或重新绑定；
3. 数据库连接字符串与访问凭证是否更新；
4. 存储配额与限速配置是否丢失。
3.5 隔离蓝图对账清单
为支撑后续跨环境迁移风险对账，以下清单总结了租户隔离蓝图中必须验证的关键项：
| 维度 | 检查项 | 验证方法 | 风险等级 |
|---|---|---|---|
| 架构模型 | 租户模型是否与升级目标集群匹配 | 对比集群配置与租户需求文档 | 高 |
| 资源隔离 | ResourceQuota / LimitRange 是否完整迁移 | kubectl get quota -A --export |
中 |
| 网络隔离 | NetworkPolicy 规则是否在新集群生效 | 端到端连通性测试 | 高 |
| 数据隔离 | PVC 绑定与存储后端是否一致 | 检查 PV/PVC 状态与 StorageClass | 高 |
| 密钥与加密 | 租户专属密钥是否可用 | 解密测试 / KMS 状态检查 | 高 |
最佳实践： 将上述清单纳入集群升级的预检脚本中，每次升级前自动执行对账，输出差异报告。隔离策略的遗漏往往是升级后生产事故的首要原因。