可观测数据驱动调度：华为云 CCE Volcano 负载感知调度实践

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。

华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。

▍为什么需要负载感知调度

1. Pod Request 值与真实资源使用错配

业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。

2. 监控数据更新和调度决策之间存在时间差

短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。

3. 批量下发和滚动升级会放大偏差

单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。

在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。

▍CCE 负载感知调度架构核心方案

在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。

▲ CCE Volcano 负载感知调度架构

1. 引入真实负载

CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。

2. 引入影子负载

对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。

3. 引入 Pod 资源预估

对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。

4. 把这些信息接入调度流程

在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：

节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力

CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：

• Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；
• NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低

▍关键实现要点

1. 影子负载缓存解决监控滞后问题

影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。

2. Pod 资源预估公式

对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request） × burst_ratio)× applied_risk_factor

3. 高水位风险保护让调度更保守

当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。

4. 预估值回滚一致性

CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。

5. 支持业务化调优

Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。

下面是一个配置示例：

actions: "enqueue, allocate, backfill"
tiers:
  - plugins:
      - name: usage
        enablePredicate: false
        arguments:
          usage.weight: 5
          cpu.weight: 1
          memory.weight: 1
          thresholds:
            cpu: 80
            mem: 80
          estimator:
            request_ratio: 0.7
            burst_ratio: 0
            risk_threshold: 0.6
            risk_factor: 1.2
            be_cpu: 250m
            be_mem: 200Mi
metrics:
  type: prometheus
  address: http://prometheus:9090
  interval: 30s

参数说明

▍效果验证

下面将介绍如何在华为云CCE集群上验证这个特性的效果。

在华为云 CCE 集群使用 Volcano 负载感知调度能力

1. 开启负载感知调度

关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：https://support.huaweicloud.com/usermanual-cce/cce_10_0789.html

2. 环境准备

CCE集群环境信息：

2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。

3. 验证调度效果

环境现状

通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值

这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。

执行操作

• 下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；
• 加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；
• 在 Deployment 稳定运行后，进行两次滚动升级操作。

预期结果

集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：

1. 集群中每个节点的真实压力；
2. 同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。

这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。

实际结果

批量下发一批新负载后的结果。

第一次滚动升级后的调度结果：

第二次滚动升级后的调度结果：

可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。

▍演进方向

Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：

• 异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。
• 节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。
• 预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本

▍总结

负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。

Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：

• 真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；
• 影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；
• 资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；
• 快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。

对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。

华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。

参考资料

• CCE Volcano 负载感知调度官方文档：https://support.huaweicloud.com/usermanual-cce/cce_10_0789.html
• Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/

关注魔方公众号，获取更多前沿资讯

添加社区小助手k8s2222，进入CCE技术交流群