3. 租户隔离模型：Namespace、ClusterScope、Multi-Tenancy 设计模式

在集群升级场景中，租户隔离是保障业务互不干扰的基石。Kubernetes 原生提供了 Namespace 作为软隔离单元，但在多团队、多环境、多集群联邦的复杂治理需求下，仅靠 Namespace 远远不够。本章深入剖析三种核心隔离模型：Namespace 级隔离、ClusterScope 级隔离以及Multi-Tenancy 设计模式，并给出 Resource Model 治理视角下的选型与落地建议。

3.1 三种隔离模型对比

3.2 Namespace 级隔离：Resource Model 治理要点

Namespace 是 Kubernetes 最基础的隔离单元。在 Resource Model 治理中，Namespace 承担了资源域的角色。治理要点包括：

• 命名规范： 采用 <tenant>-<env>-<app> 格式，例如 team-a-prod-frontend，便于自动化工具识别。
• 资源配额： 每个 Namespace 必须绑定 ResourceQuota 和 LimitRange，防止单个租户资源抢占。
• 网络策略： 默认拒绝所有入站流量，仅允许同 Namespace 或指定 Namespace 的通信。
• RBAC 绑定： 使用 RoleBinding 而非 ClusterRoleBinding，确保权限不泄露。
• 升级策略： 升级时优先验证核心 Namespace，再按租户优先级分批升级。

# 示例：Namespace 级 ResourceQuota 定义
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: team-a-prod-frontend
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "5"
    pods: "50"

3.3 ClusterScope 级隔离：全局资源治理

ClusterScope 资源（如 ClusterRole、ClusterRoleBinding、PV、StorageClass、CRD）作用于整个集群。在升级过程中，这些资源的变更会波及所有租户。治理策略如下：

• 最小权限原则： 避免为租户创建 ClusterRoleBinding，优先使用 RoleBinding + 跨 Namespace 权限委托。
• 全局策略引擎： 使用 OPA/Gatekeeper 或 Kyverno 定义 ClusterPolicy，限制租户对全局资源的访问。
• CRD 版本管理： 升级前必须检查 CRD 的存储版本与 serving 版本，确保所有租户的 CR 兼容。
• PV/PVC 治理： 使用 StorageClass 的 allowedTopologies 和 mountOptions 约束租户存储行为。

3.4 Multi-Tenancy 设计模式：Resource Model 架构

Multi-Tenancy 设计模式通过引入租户控制平面，将 Namespace 和 ClusterScope 资源统一编排。常见的实现模式包括：

1. Virtual Cluster 模式： 每个租户拥有独立的控制平面（如 vCluster），底层共享物理节点。Resource Model 治理聚焦于虚拟集群的 API 资源配额和 CRD 同步。
2. Cell 模式： 将集群划分为多个 Cell（细胞单元），每个 Cell 包含一组 Namespace 和专属的 ClusterScope 资源。升级时以 Cell 为单位进行灰度。
3. Hierarchical Namespace 模式： 使用 HNC（Hierarchical Namespace Controller）创建租户级 Namespace 树，父 Namespace 的策略自动继承到子 Namespace。

3.5 升级场景下的隔离模型选型矩阵

3.6 实践案例：基于 HNC 的租户隔离 Resource Model

以下是一个基于 Hierarchical Namespace Controller（HNC）的 Resource Model 示例。通过定义租户父 Namespace，子 Namespace 自动继承资源配额和网络策略。

# 租户父 Namespace 定义
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a
  annotations:
    hnc.x-k8s.io/managed-by: "hnc"
---
# 子 Namespace 自动继承父 Namespace 的 ResourceQuota
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a-prod
  annotations:
    hnc.x-k8s.io/parent: "tenant-a"
---
# 父 Namespace 的 ResourceQuota 模板
apiVersion: hnc.x-k8s.io/v1alpha2
kind: ResourceQuotaTemplate
metadata:
  name: tenant-quota-template
  namespace: tenant-a
spec:
  spec:
    hard:
      requests.cpu: "20"
      requests.memory: "40Gi"
      limits.cpu: "40"
      limits.memory: "80Gi"

3.7 升级前隔离模型健康检查清单

• Namespace 清单： 确认所有 Namespace 已绑定 ResourceQuota、LimitRange、NetworkPolicy。
• ClusterScope 清单： 确认 ClusterRole 和 ClusterRoleBinding 未过度授权；CRD 版本已标记存储版本。
• Multi-Tenancy 清单： 确认租户控制平面版本与集群版本兼容；租户资源模板已备份。
• 策略引擎清单： 确认 OPA/Gatekeeper 或 Kyverno 策略未因升级产生冲突。
• 监控与告警： 确认租户隔离相关的监控指标（如 Namespace 资源使用率、策略拒绝次数）已配置告警。