3. 租户边界概念：Namespace as a Service、虚拟集群、租户资源隔离模型
在多集群与多租户场景中，租户边界是资源版本差异校验的逻辑起点。没有清晰的租户边界，版本校验就无法确定“谁的资源需要被校验”以及“校验范围在哪里”。本章从三个递进层次解析租户边界：Namespace as a Service (NaaS)、虚拟集群 (Virtual Cluster)、租户资源隔离模型。
3.1 租户边界的三个层次
租户边界并非单一概念，而是从“资源分组”到“控制面隔离”再到“策略模型”的逐层深化。下表对比了三个层次的核心特征：
| 层次 | 核心概念 | 隔离粒度 | 控制面开销 | 典型场景 |
|---|---|---|---|---|
| Namespace as a Service | 将 Namespace 作为租户的交付单元，通过 RBAC/NetworkPolicy 实现软隔离 | 单 Namespace | 低（共享 API Server） | 开发环境、轻量级多租户 |
| 虚拟集群 | 在物理集群之上创建逻辑集群，每个租户拥有独立的 API 端点与资源视图 | 虚拟控制面 | 中（虚拟 API Server 代理） | SaaS 平台、合规敏感业务 |
| 租户资源隔离模型 | 定义租户间资源可见性、配额、网络与安全策略的完整模型 | 策略驱动 | 高（策略引擎 + 审计） | 金融、医疗、政府多租户 |
实践建议：在版本差异校验场景中，NaaS 适用于“同一集群内不同 Namespace 的版本基线对比”；虚拟集群适用于“跨逻辑集群的版本一致性校验”；而隔离模型决定了校验策略的生效范围与优先级。
3.2 Namespace as a Service (NaaS)
NaaS 是 Kubernetes 原生多租户的最轻量实现。其核心思想是：将 Namespace 视为租户的“最小交付单元”，每个租户获得一个或多个 Namespace，并通过 RBAC、ResourceQuota、NetworkPolicy 实现资源与安全隔离。
NaaS 的关键组件：
- RBAC：通过 Role/ClusterRole + RoleBinding 限制租户的操作范围。
- ResourceQuota：限制租户的 CPU、内存、存储等资源总量。
- NetworkPolicy：控制租户内/租户间的网络流量。
- LimitRange：设置 Pod/Container 的默认资源请求与限制。
NaaS 在版本校验中的局限：
- 共享 API Server：租户仍可看到集群级别的资源（如 Node、PV），存在信息泄露风险。
- 版本差异校验只能基于 Namespace 内的资源版本，无法感知集群级版本变化。
- 跨 Namespace 的资源依赖（如 Service 跨 Namespace 调用）会增加校验复杂度。
3.3 虚拟集群 (Virtual Cluster)
虚拟集群通过为每个租户创建独立的逻辑控制面，解决了 NaaS 的共享 API Server 问题。每个虚拟集群拥有独立的 API 端点、资源视图和版本基线，但底层共享同一个物理集群的计算与存储资源。
主流实现方式：
- vcluster (Loft)：在物理集群中运行一个“集群 Pod”，该 Pod 内嵌 API Server、Controller Manager 和 Storage Backend（etcd 或 SQLite）。
- Kiosk / KubeVela：通过 API 代理与资源映射实现虚拟集群。
- Kubernetes 原生虚拟集群 (KubeVirt)：适用于虚拟机场景，但原理类似。
版本校验优势：虚拟集群的每个租户拥有独立的资源版本快照，校验时只需对比“虚拟集群的版本基线”与“物理集群的实际版本”，无需跨 Namespace 聚合。这大幅降低了校验的复杂度与误报率。
3.4 租户资源隔离模型
租户资源隔离模型定义了租户间资源可见性、配额分配、网络策略与安全策略的完整规则。在多集群版本差异校验中，隔离模型决定了校验策略的生效范围与优先级。
常见的隔离模型：
| 模型名称 | 资源可见性 | 网络隔离 | 版本校验范围 | 适用场景 |
|---|---|---|---|---|
| 软隔离 (Soft Multi-Tenancy) | 租户可见集群级资源 | NetworkPolicy 控制 | Namespace 级别 | 开发/测试环境 |
| 硬隔离 (Hard Multi-Tenancy) | 租户仅见自身资源 | VPC / CNI 隔离 | 虚拟集群级别 | 生产环境、合规场景 |
| 混合隔离 (Hybrid Multi-Tenancy) | 部分共享 + 部分隔离 | 分层策略 | 按策略动态调整 | 大型 SaaS 平台 |
版本校验陷阱：在软隔离模型中，如果两个租户共享同一个 Namespace 的某些资源（如 ConfigMap），版本差异校验可能会产生“假阳性”告警。建议在软隔离场景中，为每个租户创建独立的 Namespace，并明确资源归属。
3.5 租户边界与版本校验的映射关系
在 cluster inventory 的版本差异校验流程中，租户边界直接决定了校验单元与校验策略：
- NaaS 模式：校验单元为
Namespace，校验策略为“同一集群内不同 Namespace 的版本对比”。 - 虚拟集群模式：校验单元为
Virtual Cluster，校验策略为“虚拟集群版本基线 vs 物理集群实际版本”。 - 隔离模型：校验单元为
Tenant，校验策略为“按隔离模型定义的资源范围进行版本对比”。
3.6 实践建议：如何选择租户边界模型
在 cluster inventory 的版本差异校验项目中，选择租户边界模型需考虑以下因素：
- 安全合规要求：金融、医疗等场景优先选择虚拟集群或硬隔离模型。
- 资源利用率：NaaS 模式资源利用率最高，但隔离性最弱。
- 版本校验精度：虚拟集群模式提供最精确的版本基线，适合跨集群版本一致性校验。
- 运维复杂度：NaaS 模式运维最简单，虚拟集群需要额外的控制面组件管理。
推荐组合：在大型多集群环境中，建议采用“虚拟集群 + 硬隔离模型”的组合。每个租户拥有独立的虚拟集群，虚拟集群内部再通过 NaaS 进行细粒度资源分组。版本差异校验时，先校验虚拟集群的版本基线，再校验 Namespace 级别的资源版本。