2. 资源抽象模型设计:统一资源描述、拓扑树与超卖模型

在跨集群联邦调度场景中,每个集群的硬件配置、资源管理策略、调度器行为均存在差异。为了在联邦控制面实现全局最优调度,必须设计一套资源抽象模型,将底层异构资源统一为联邦层可理解、可比较、可预留的标准化描述。本章围绕三个核心设计展开:统一资源描述(URD)、资源拓扑树(Topology Tree)以及资源预留与超卖模型。

2.1 统一资源描述(Unified Resource Description, URD)

统一资源描述是联邦资源模型的原子单元,用于标准化表达每个成员集群中节点的计算资源。URD 不仅覆盖 CPU、Memory、GPU 等传统资源,还需包含资源属性标签(如 GPU 型号、NUMA 拓扑、是否可超卖)。

资源类型 URD 字段 示例值 说明
CPU cpu.cores 32 物理核数(非 vCPU)
CPU cpu.architecture x86_64 / arm64 指令集架构
Memory memory.bytes 128Gi 总物理内存
Memory memory.type DDR5 / HBM 内存类型
GPU gpu.count 4 物理 GPU 卡数
GPU gpu.model NVIDIA A100 GPU 型号
GPU gpu.memory 80Gi 单卡显存
扩展 extended.overcommit true 是否允许超卖
设计原则:URD 采用扁平键值对结构,避免嵌套过深导致序列化膨胀。所有资源单位统一使用二进制前缀(Gi、Mi),联邦调度器在比较时无需单位转换。

2.2 资源拓扑树(Topology Tree)

单一节点的资源描述不足以支撑跨集群调度决策。资源拓扑树将节点内部的硬件拓扑(NUMA 域、GPU 互联、缓存层级)以及集群间的网络拓扑(AZ、Region、Edge)组织为分层树结构,使联邦调度器能够感知资源局部性。

拓扑树层级定义(从根到叶):
  • L0 - Federation Root: 全局联邦根节点,包含所有成员集群。
  • L1 - Region / Cloud Provider: 地理区域或云厂商边界。
  • L2 - Cluster: 单个 Kubernetes 集群,拥有独立的 API Server 和调度器。
  • L3 - Node: 集群内的物理或虚拟节点。
  • L4 - NUMA Domain / GPU Group: 节点内的硬件亲和域。
  • L5 - Resource Unit: 单个 CPU 核、内存条、GPU 卡。
资源拓扑树(Topology Tree)层级结构 L0: Federation Root L1: Region A L1: Region B L2: Cluster-1 L2: Cluster-2 L2: Cluster-3 L2: Cluster-4 Node-A1 Node-A2 Node-C1 Node-C2 NUMA-0 NUMA-1 GPU-Group Core-0 Core-1 GPU-0 GPU-1 说明: 拓扑树从 Federation Root 向下逐层细化,每层携带资源聚合信息(总容量、已分配、可用)。 联邦调度器在决策时优先选择拓扑距离最近的资源域,以减少跨 NUMA 或跨 Region 的网络开销。

2.3 资源预留与超卖模型

联邦调度需要同时支持预留(Reservation)和超卖(Overcommit)两种模式。预留保证关键工作负载的资源独占性;超卖则提升资源利用率,但需要引入准入控制和驱逐机制。

2.3.1 预留模型

预留通过在拓扑树的特定层级(Cluster 或 Node)创建资源预留对象(ResourceReservation)实现。预留对象包含资源需求量、时间窗口、优先级和弹性策略。

apiVersion: federation.resource/v1
kind: ResourceReservation
metadata:
  name: ai-training-reservation
spec:
  target:
    clusterSelector:
      matchLabels:
        region: "us-east"
        gpu-type: "A100"
  resources:
    cpu: 64
    memory: "512Gi"
    gpu: 8
  timeWindow:
    start: "2025-06-01T00:00:00Z"
    end: "2025-06-30T23:59:59Z"
  priority: 100
  elasticity:
    overcommitRatio: 1.0   # 1.0 表示不超卖

2.3.2 超卖模型

超卖模型允许调度器将同一份物理资源分配给多个 Pod,但需满足以下约束:

  • 静态超卖比: 在 URD 中声明 overcommitRatio,例如 CPU 超卖比 2.0 表示逻辑容量 = 物理容量 × 2。
  • 动态准入: 基于实时负载的 usageWatermark 动态调整可调度容量,避免节点过载。
  • 驱逐优先级: 超卖 Pod 被标记为 burstable 或 best-effort,在资源紧张时优先被驱逐。
工程陷阱: 超卖模型必须与集群本地调度器(kube-scheduler)协同。联邦层超卖决策若与本地调度策略冲突,可能导致 Pod 调度失败或节点过载。建议在联邦层只做“容量建议”,由本地调度器执行最终绑定。
资源预留与超卖调度流程 联邦调度请求 是否预留? 预留匹配 超卖准入 绑定到目标集群 动态容量调整 驱逐低优先级 预留路径:直接匹配预留对象,资源独占。超卖路径:通过动态准入控制,允许超卖比 1.5~3.0,但需配合驱逐机制保障稳定性。

2.4 模型对比与选型建议

特性 统一资源描述 (URD) 资源拓扑树 预留模型 超卖模型
核心目标 标准化资源表达 感知拓扑局部性 资源独占保障 提升利用率
数据粒度 单资源项 节点 → 集群 → Region 时间 + 资源量 逻辑容量
调度影响 比较与过滤 优先级排序 硬约束 软约束 + 驱逐
适用场景 所有调度决策 延迟敏感、GPU 拓扑 训练任务、数据库 批处理、CI/CD
落地建议: 在联邦调度器内部,URD 作为资源比较的原子单位;拓扑树用于构建调度优先级队列;预留与超卖模型通过独立的 ResourceReservation 和 OvercommitProfile CRD 实现,与调度器主流程解耦。推荐在初始阶段仅启用预留模型,待稳定性验证后再逐步引入超卖。