Kubernetes多租户集群滚动升级与故障恢复 - 第2节
2.1 资源模型的核心概念
资源模型（Resource Model）是云原生平台对基础设施、中间件、应用组件进行统一抽象与编排的元数据框架。在租户隔离蓝图中，资源模型定义了“有什么资源”“资源长什么样”“资源之间如何连接”三个基本问题，是滚动升级故障排查的语义基础。
2.1.1 资源类型（Resource Type）
资源类型是对一类具有相同属性、行为和生命周期管理方式的资源所做的分类定义。每个资源类型包含：
- 类型标识：全局唯一的类型名称，如
TenantNamespace、NetworkPolicy、ServiceMesh。 - 属性模式：描述该类型资源必须或可选包含的字段，如
tenantId、quota.cpu、quota.memory。 - 生命周期钩子：创建、更新、删除、健康检查等阶段触发的控制器行为。
- 版本约束：资源类型的 API 版本与兼容性规则。
| 资源类型 | 典型属性 | 生命周期钩子 | 版本约束 |
|---|---|---|---|
TenantNamespace |
tenantId, namespaceName, quota | 创建时自动绑定 RBAC | v1, v2（新增隔离策略） |
NetworkPolicy |
policyName, ingressRules, egressRules | 更新时触发流量重算 | v1 |
ServiceMesh |
meshId, sidecarVersion, mtlsMode | 升级时执行金丝雀注入 | v1, v2（sidecar 协议变更） |
QuotaTemplate |
cpuLimit, memoryLimit, storageLimit | 更新时重新分配租户额度 | v1 |
故障排查要点：滚动升级过程中，如果资源类型的版本约束未在蓝图声明中同步更新，控制器可能因 schema 校验失败而拒绝创建新实例，导致升级卡在“等待就绪”状态。
2.1.2 资源实例（Resource Instance）
资源实例是资源类型在运行时环境中的具体化对象。每个实例拥有唯一的标识符（UID）、当前状态（Status）、期望状态（Spec）以及元数据（Metadata）。实例的状态机通常包含以下阶段：
- Pending：实例已提交，但尚未被控制器处理。
- Provisioning：控制器正在创建或更新底层基础设施。
- Ready：实例已就绪，对外提供服务。
- Upgrading：实例正在执行滚动升级，部分副本处于过渡状态。
- Degraded：实例部分功能异常，但未完全失效。
- Failed：实例无法恢复，需要人工介入。
# 资源实例的 YAML 表示示例（简化）
apiVersion: blueprint.tenant.io/v1
kind: TenantNamespace
metadata:
name: tenant-alpha-ns
uid: a1b2c3d4-e5f6-7890-abcd-ef1234567890
spec:
tenantId: "alpha"
quota:
cpu: "4"
memory: "16Gi"
status:
phase: Ready
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2025-03-10T08:00:00Z"
升级故障场景：当资源实例处于
Upgrading 状态时，如果依赖的下游实例尚未完成升级，会导致级联等待超时。排查时应优先检查实例的 status.conditions 中是否包含 DependencyBlocked 类型。
2.2 资源关系图（Resource Relationship Graph）
资源关系图将资源类型与资源实例组织为有向无环图（DAG），描述资源之间的依赖、组合、引用和约束关系。在租户隔离蓝图中，关系图是滚动升级顺序编排的核心依据。
2.2.1 关系类型定义
| 关系类型 | 语义 | 示例 |
|---|---|---|
| 依赖（DependsOn） | 源资源必须等待目标资源就绪后才能操作 | ServiceMesh 依赖 TenantNamespace |
| 组合（ComposedOf） | 源资源由多个目标资源组合而成 | TenantBlueprint 组合 NetworkPolicy + QuotaTemplate |
| 引用（References） | 源资源通过标识符引用目标资源 | NetworkPolicy 引用 TenantNamespace 的 namespaceName |
| 约束（Constrains） | 源资源对目标资源的属性施加限制 | QuotaTemplate 约束 TenantNamespace 的 quota 上限 |
2.2.2 资源关系图结构
下图展示了一个典型租户隔离蓝图中的资源关系图。节点代表资源类型，有向边代表依赖与组合关系。滚动升级时，控制器按照拓扑排序从底层依赖向上层逐层推进。
2.2.3 关系图在滚动升级中的作用
资源关系图驱动滚动升级的以下关键决策：
- 升级顺序：控制器对 DAG 进行拓扑排序，确保无依赖的资源先升级，有依赖的资源后升级。
- 并发控制：同一层级的无依赖资源可以并行升级，提升效率；跨层级的资源必须串行等待。
- 故障隔离：当某个资源实例升级失败时，关系图可快速定位受影响的下游资源，避免故障扩散。
- 回滚范围：回滚时，控制器根据关系图反向传播，确保所有依赖该资源的实例也一并回滚。
排查案例：在一次租户隔离蓝图滚动升级中，
ServiceMesh 升级后 TenantBlueprint 一直处于 Upgrading 状态。通过分析资源关系图发现，ServiceMesh 与 TenantBlueprint 之间存在 ComposedOf 关系，但 ServiceMesh 的新版本 sidecar 协议与 NetworkPolicy 的 ingress 规则不兼容，导致组合校验失败。修复 NetworkPolicy 的规则后，升级继续完成。
2.3 资源模型与租户隔离的映射
在租户隔离蓝图中，资源模型通过以下机制实现多租户隔离：
| 隔离维度 | 资源模型映射 | 升级影响 |
|---|---|---|
| 命名空间隔离 | 每个租户对应一个 TenantNamespace 实例 |
升级时需保持命名空间标签不变，避免网络策略失效 |
| 网络隔离 | NetworkPolicy 实例绑定到租户命名空间 |
升级期间需保留最小权限规则，防止流量中断 |
| 配额隔离 | QuotaTemplate 实例约束租户资源上限 |
升级时配额模板变更可能导致正在运行的 Pod 被驱逐 |
| 服务网格隔离 | ServiceMesh 实例为租户提供独立 sidecar 代理 |
升级 sidecar 版本需确保与网格控制面兼容 |