3、租户隔离模型设计：Namespace隔离、RBAC隔离、资源配额隔离

在基于 Resource Model 的租户隔离升级场景中，隔离模型的设计直接决定了故障半径和运维效率。本章聚焦三层核心隔离机制：Namespace 隔离（资源边界）、RBAC 隔离（权限边界）、资源配额隔离（容量边界）。三者共同构成“物理-逻辑-策略”的纵深防御体系。

3.1 三层隔离模型总览

下表对比了三层隔离的职责、作用对象和典型故障场景：

隔离层 核心职责 作用对象 升级故障典型表现
Namespace 隔离 资源命名空间与网络边界 Pod、Service、ConfigMap 跨 Namespace 服务发现失败、DNS 解析超时
RBAC 隔离 操作权限与角色绑定 User、ServiceAccount、Role 升级后 API 调用返回 403、控制器无法 List/Watch
资源配额隔离 资源上限与抢占控制 CPU、Memory、存储、对象计数 Pod 调度失败、ResourceQuota 冲突、LimitRange 拒绝
设计原则：三层隔离必须独立配置但协同生效。升级过程中，任意一层被绕过或配置遗漏，都会导致租户数据泄露或服务中断。

3.2 Namespace 隔离：资源边界

Namespace 是 Kubernetes 中最基础的隔离单元。在 Resource Model 中，每个租户对应一个或多个 Namespace，通过 NetworkPolicy 实现网络隔离，通过 ResourceQuota 实现容量隔离。

升级故障排查要点：

  • DNS 解析域变更：升级后 CoreDNS 配置可能重置，导致 <service>.<namespace>.svc.cluster.local 解析失败。
  • NetworkPolicy 未迁移：旧版本 NetworkPolicy 的 podSelector 或 namespaceSelector 在新版本中语义变化，导致流量被意外阻断。
  • Namespace 标签丢失：升级过程中 Namespace 的 label 被清除，影响基于标签的 RBAC 和 NetworkPolicy 匹配。
故障案例：某金融租户升级后，跨 Namespace 的 gRPC 调用全部超时。排查发现 CoreDNS 升级后未加载租户自定义域名映射，导致 svc.cluster.local 解析指向错误 IP。
Namespace 隔离架构与升级故障点 Namespace 隔离架构与升级故障点 租户 A Namespace Pod A1 Pod A2 Service A: svc-a.tenant-a.svc NetworkPolicy: deny-all ResourceQuota: CPU 8, Mem 16Gi 租户 B Namespace Pod B1 Pod B2 Service B: svc-b.tenant-b.svc NetworkPolicy: allow-same-ns ResourceQuota: CPU 16, Mem 32Gi ⚠ 升级故障点：DNS 解析域变更、NetworkPolicy 语义漂移、Namespace 标签丢失 跨 Namespace 调用

3.3 RBAC 隔离：权限边界

RBAC 控制每个主体（User、Group、ServiceAccount）对资源的操作权限。在升级场景中，RBAC 隔离的常见故障包括：

  • Role 与 ClusterRole 混淆：升级后控制器使用的 ClusterRole 被重置为默认值，导致跨 Namespace 的 List/Watch 权限丢失。
  • Subject 变更：ServiceAccount 的 namespace 或 name 在升级过程中被修改，导致 RoleBinding 失效。
  • API 组版本升级：旧版 RBAC 规则引用的 API 组（如 extensions/v1beta1）在新版本中被移除，导致权限检查失败。
升级前必检：使用 kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> 验证每个租户 ServiceAccount 的权限集合，确保升级后权限不降级。

3.4 资源配额隔离：容量边界

ResourceQuota 和 LimitRange 共同保障租户的资源使用上限。升级过程中配额隔离的典型问题：

  • 配额对象计数变更：新版本 Kubernetes 增加了新的计费对象（如 count/ingresses.extensions），旧配额未包含导致创建失败。
  • LimitRange 默认值冲突：升级后 LimitRange 的默认 request/limit 与 Pod 的 QoS 策略冲突，导致 Pod 被拒绝。
  • 资源单位精度变化：CPU 从 millicores 到 cores 的转换误差，导致配额计算溢出。
资源配额隔离与升级冲突 资源配额隔离与升级冲突 租户 A 配额池 CPU: 8 cores 已用: 6.5 cores Memory: 16 Gi 已用: 12 Gi 对象计数: Pods 20/50, Services 5/10 租户 B 配额池 CPU: 16 cores 已用: 15.8 cores Memory: 32 Gi 已用: 28 Gi 对象计数: Pods 45/50, Services 8/10 ⚠ 升级冲突：新版本增加 count/ingresses 对象，旧配额未包含 → 创建 Ingress 被拒绝 配额竞争

3.5 三层隔离的协同故障排查矩阵

当升级后出现租户隔离故障时，建议按以下矩阵进行分层排查：

故障现象 Namespace 层 RBAC 层 资源配额层
Pod 无法跨 Namespace 通信 检查 NetworkPolicy 和 DNS 检查 ServiceAccount 权限 无需排查
API 返回 403 Forbidden 检查 Namespace 标签 检查 RoleBinding 和 ClusterRole 无需排查
Pod 调度失败 Pending 检查 Namespace 是否存在 检查 ServiceAccount 是否存在 检查 ResourceQuota 和 LimitRange
控制器无法 List 资源 检查 Namespace 是否被删除 检查 ClusterRole 的 API 组版本 检查对象计数配额
最佳实践：在升级前使用 kubectl diff 对比新旧版本的 RBAC 规则和 ResourceQuota 配置，生成“隔离配置差异报告”。升级后立即执行租户隔离验证脚本，覆盖 DNS 解析、权限校验、配额边界三个维度。
← 上一章 📖 返回目录 下一章 →