在离线统一调度器 Gödel Scheduler 性能优化: 算法设计思想与数据结构应用

基于优异的调度性能，Gödel Scheduler 拥有在超大集群规模 (20k+ Nodes, 1000k+ Pods)、超高业务负载 (1k+ Incoming Pods/s)、超多复杂场景 (ML/批流/潮汐混部等) 下长期稳定运行的能力。

来源 | KubeWharf 社区

项目 | github.com/kubewharf/godel-scheduler

Gödel Scheduler 是字节跳动开源的在离线统一调度器，旨在使用同一套调度器来统一调度和管理在离线业务，实现资源并池，从而在提升资源利用率和资源弹性的同时，优化业务成本和体验，降低运维压力。

当前，Gödel Scheduler 的单分片调度吞吐可达 2500+ Pods/s (10x Kube Scheduler)，多分片调度吞吐可达 5000+ Pods/s，这离不开大量创造性的构思。

本文将以几个经典优化为例，阐述基于这些构思所衍生的算法设计思想与数据结构应用，说明其对提升 Gödel Scheduler 调度性能并最终解决实际问题所发挥的巨大作用。

设计一：增量更新

前置介绍

与 Kube Scheduler 相似，Gödel Scheduler 同样维护了 In Memory 的 Cache 与 Snapshot。

Cache:

• 维护各类 Resource Object 的组织关系，有助于快速获得汇聚信息 (如节点已被使用的资源总量)，提高调度算法的执行效率

• 会伴随着 Event 触发实时变动，且数据维护需要对整个 Cache 加锁

Snapshot:

• 规避当前调度轮次期间 Event 带来的影响，保证调度过程中的数据一致性

• 单个调度轮次期间数据只读，不需要加锁

每次调度流程的起始都需要将 Cache 的最新数据同步 Clone 到 Snapshot 中供串行的调度流程取用，因此数据同步的效率就格外关键。

问题产生与解决

相比于 Kube Scheduler，Gödel Scheduler 拥有更复杂的调度功能、需要承载更大规模的集群与应用，并由此带来了更多种类的缓存信息与更大量级的数据同步规模。此前，伴随着业务上量与集群规模自然增长，大量生产集群都频繁出现了各类缓存信息全量克隆所产生的性能问题，并严重拖垮了调度吞吐与调度时延。