Gödel Rescheduler：适用于云原生系统的全局最优重调度框架

在云原生调度中，一次调度往往无法解决所有问题，需要配合重调度来优化资源分配和任务摆放。一方面，初始调度时所依据的资源信息，可能由于后续任务的启动、停止或资源争用等原因发生变化。

另一方面，随着业务的发展和用户需求的变化，新的任务不断被提交到集群中，这些新任务对资源的需求和依赖关系各不相同，一次调度很难预先考虑到所有这些因素，从而导致部分任务无法获得最优的资源分配，进而影响任务的执行效率和集群的整体性能。

为此，字节跳动研发了 Gödel Rescheduler——一个适用于全局最优调度策略的重调度框架。它不仅能识别集群中的异常节点和任务，还能智能推荐任务到最合适的位置，并通过图算法生成详细的迁移步骤，确保集群的整体稳定性，真正实现全局最优调度。

项目地址：https://github.com/kubewharf/godel-rescheduler

在 5 月 17 日举办的字节跳动云原生技术沙龙·上海站上，ByteDance Director of Engineering 谢立广，ByteDance Researcher 徐乐，哔哩哔哩资深开发工程师戴一帆，字节跳动云原生资深工程师宋心怡，蚂蚁集团云原生技术专家，KusionStack 开源负责人、Maintainer 陈在，五位技术专家带来多个精彩主题分享，共同探讨 AI 时代下的云原生技术，有哪些前沿解决方案与实践经验。

其中，宋心怡带来了主题为《Gödel Rescheduler：适用于云原生系统的全局最优重调度框架》的主题演讲，分享了 Gödel Rescheduler 的设计理念与技术实现，揭示其如何通过全局最优调度策略，解决传统调度中的资源碎片化和任务摆放不合理问题。本文整理自该演讲分享，经编辑。

传统重调度方案核心挑战

在探讨为何要开展 Gödel Rescheduler 的研发工作之前，有必要先了解当前调度领域中常见的一次调度机制。比如 Kubernetes Scheduler 以及字节跳动自主研发的 Gödel Scheduler，这类调度器通常面临性能方面的严格要求，研发团队始终致力于在调度质量与调度速度之间寻求平衡，力求实现两者的双赢。

然而，在实际应用场景中，为了满足更高的吞吐量需求，往往不得不在一定程度上牺牲调度质量。即便在一次调度过程中，能够为每个实例找到最为合适的部署节点，但随着集群状态的变化，原本合理的部署方案可能逐渐变得不再适用。例如，当某些实例运行结束后退出集群，其所在节点上仍在运行的其他实例，或许就存在更优的部署位置。为了对这种不合理的部署进行优化调整，实现实例的重新合理部署，重调度器的引入显得尤为必要。

但传统的重调度器方案存在诸多弊端。首先，其触发条件较为单一，通常仅以周期性执行作为唯一的触发条件。并且，当多个不同策略在同一集群中部署时，它们均以相同的周期运行，这极大地限制了重调度器的灵活性，导致重调度效果难以达到预期。

其次，传统重调度方案难以保障集群的稳定性。若在集群中部署多个策略，这些策略之间可能会产生冲突。例如，策略 A 将某个实例从节点一迁移至节点二，策略 B 又将该实例从节点二移回节点一。这种策略间的冲突会对实例的稳定性造成严重影响，进而导致整个服务对外提供的性能和质量大打折扣。

此外，传统重调度方案存在不推荐节点的缺陷，其功能更倾向于“杀死”实例，而非真正意义上的重新调度。在这种模式下，被“杀死”的实例有可能无法找到合适的部署位置，即使侥幸找到，也可能并非最优选择。在下一轮重调度过程中，这些实例很可能再次被“杀死”，从而导致服务长期处于不稳定状态。

为了解决传统重调度方案中存在的灵活性不足、集群稳定性难以保障等问题，字节跳动提出了全新的重调度方案。该方案主要由两个组件协同工作，即 Gödel Rescheduler 和 Gödel Scheduler。其中，Gödel Scheduler 作为实时一次调度器，位于框架右下角；而 Gödel Rescheduler 负责重调度算法策略的运行与执行，涵盖旧实例的删除以及推荐结果的同步，并将同步结果提供给 Gödel Scheduler，以便 Gödel Scheduler 在调度新实例时优先将其部署到推荐节点上。

Gödel Rescheduler 项目框架与组件设计

Policy Manager：算法与策略控制中心

Gödel Rescheduler 的第一个子模块叫做 Policy Manager。Policy Manager 作为算法与策略控制中心，承担着配置重调度策略、进行迁移条件检测以及执行相应算法的任务，旨在输出全局或局部最优的调度结果，并将策略传递给 Movement Manager。

Policy Manager 负责读取并解析配置文件，用户可以在配置文件中定义重调度策略的触发条件、参数及作用范围。该方案提供了四种触发方式，包括周期执行、信号触发、HTTP 请求触发以及 Cronjob 执行。每种策略可根据实际需求配置一种或多种触发方式，有效解决了传统方案灵活性不足的问题。

当 Policy Manager 配置触发一次重调度时，便进入 Detector 环节。Detector 以 Plugin 的方式接入框架，每种重调度策略需定制化其 Detector，以实现不同的检测逻辑，用于检测集群机器和实例状态，评估是否需要进行重调度。如需进行重调度，其会将评估结果传递给 Algorithm Provider。

Algorithm Provider 同样通过 Plugin 的方式接入框架，每种策略需定制化自己的 Algorithm 以实现不同的重调度逻辑。该模块会根据 Detector 提供的输入，为需要重调度的实例寻找最合适的目标节点。与传统重调度方案的区别在于，它会校验目标节点的可用性，例如资源总量和节点亲和性校验，确保推荐的节点能够通过实时调度器的所有检查。

此外，Algorithm Provider 还会进行策略冲突校验。若集群中配置了 A 和 B 两种重调度策略，它们之间必须至少存在一种校验关系，最好是能够互相校验。校验内容主要包括原节点是否允许实例移出、目标节点是否允许实例移入，以及实例是否真的可以发生移动。若三者中任何一个条件不允许进行，相应的 movement item 将被拦截。同时，还会进行稳定性校验，例如当集群中 pending 实例数量达到阈值时，判定集群处于不稳定状态，使重调度行为静默一段时间；若判断移动实例为重要保障实例，则不允许其移动；若服务实例在过去一段时间内移动频率过高，为保护服务，也会让该服务静默一段时间。

Movement Manager：决策执行与排序

前面提到，Policy Manager 的结果会输入给 Movement Manager，后者主要负责决策的执行和排序，将推荐结果上报给 Gödel Scheduler，并清除过期的推荐结果。

先来看 Movement Manager 管理的第一个子模块：Movement genterator。Movement genterator 基于有向图强连通分量分解，对所有移动进行排序和分批次处理，旨在确保任一批次并发执行时都不违反 PDB 的限制，并使批次数量最少，同时将推荐结果分批次同步给 Gödel Scheduler。

具体处理方式如下：将实例的移动序列制成一张有向图，图的节点和边代表节点上实例的移动。例如，若节点 A 上的实例需要移动到节点 B，则该移动实例（如 dp1/pod1）构成一条边。若图中任意两个节点都能通过有向边彼此到达，则该图为强连通图。虽然制成的图可能并非强连通图，但可能存在强连通子图，如节点 B、C、D、E 组成的子图。通过对子图进行缩减，可将原图制成一张有向无环图。

接着，根据拓扑逆序执行 pod 的迁移动作。例如，找到末端节点 H 和 I，随机选择一个作为第一个处理节点，如选择节点 H，将其输出实例 dp3/pod2、dp1/pod5 放入第一批次。消点后，末端实例变为节点 I，将其移动实例 dp2/pod4 加入第一批次。最后一个节点变为节点 G，判断其移动实例 dp1/pod4 是否可以放入第一批次，并考虑与前面的 dp1/pod5 是否会违反 PDB。若不违反，则放入第一批次；若违反，则进入第二批次。以此类推，可产生若干个执行批次。

最后，将批次内的推荐信息上报给 Gödel Scheduler，上报方式采用云原生常见的 CRD 方式，命名为 Movement。Movement 包含 Gödel Rescheduler、Gödel Scheduler 上传的信息。由于这个 Movement 由 Gödel Rescheduler 创建，创建时会在 Movement 中输入迁移由哪个策略产生，如 creator 为 policyA，并记录迁移序列中移动的实例信息。

在 Scheduler 中，将这些实例信息按照 owner 进行组合分类，如果这两个实例都属于 owner1（owner1 是一个 replicaset，该 owner 删除了两个实例，因此会推荐两个摆放位置），摆放位置都在节点 222 上。Gödel Scheduler 在进行实时调度时，对于 owner 下的实例，会优先将其调度到推荐节点上。例如，实例 333 按照预期调度到目标节点，进入 actualPods；而实例 222 因推荐节点因其他实例调度无法容纳，按照正常调度流程调度到其他节点，如节点 3，这些未成功使用推荐节点信息的实例会进入 mismatchedTasks，事后通过分析 Movement 可了解此次重调度推荐的使用情况。

最后，简单聊聊 Movement Manager 管理的另外两个子模块：Task killer、Movement Recycler。其中，Task Killer 负责对每个批次的实例进行删除，删除操作在保证稳定性的前提下进行，采用 evict 方式。在下一轮决策形成新的移动之前，Movement Recycler 会清除旧的调度决策，避免过期决策影响新的重调度计划。、

重调度项目在字节跳动有哪些应用实践？

在字节跳动内部，重调度项目主要有四大应用场景：合并部署、负载均衡、碎片整理、拓扑域容灾。

第一个应用场景是合并部署，其目标在于降低上下游应用之间的通信开销。为实现这一目标，项目采用了通信本地化的策略。具体而言，若节点 A 和 C 之间、节点 B 和 D 之间存在通信需求，当这些通信跨越不同节点时，将产生较大的通信开销。通过重调度，将原本需要跨节点通信的 A 和 C 部署于同一实例，B 和 D 部署于同一节点，从而显著减少通信开销。实践数据显示，该重调度策略上线后，为大量在线服务带来了显著的通信时延优化，优化幅度可达 20% - 70%，有效提升了系统的通信效率与性能。

第二个应用场景是负载均衡，其目标在于减少节点 CPU 热点和网络热点等问题，该策略依据 Profile 对节点上的 CPU 负载和网络带宽负载进行合理打散。在大规模混合部署集群的流量高峰期，通过实施此策略，热点问题得到了有效控制。例如，带宽热点节点的比例可控制在 0.1% 以内，同时，约 50% 的集群机器 CPU 热点问题也得到了显著缓解，确保了集群资源的高效利用和系统的稳定运行。

第三个应用场景是碎片整理，其目标在于降低 GPU 等资源的碎片率。在实际应用中，可能出现这样的情况：在两个节点上分别部署了少量的 GPU 服务，导致大规格的 GPU 实例无法进行调度。通过重调度策略，将一个节点上的实例重新调度至另一个节点，从而释放出一个完整的 GPU 资源，供大规格的 GPU 服务使用。实践结果表明，在数万卡的 GPU 集群中，该重调度策略能够将碎片率控制在 5%以下，有效提高了 GPU 资源的利用率，降低资源浪费。

第四个应用场景是拓扑域容灾，其目标是避免因单拓扑域故障导致服务不可用。为实现这一目标，项目采用了将业务实例在不同拓扑域进行打散的方法。以节点为例，若一个服务的所有实例均部署在同一节点上，一旦该节点发生故障，整个服务将陷入不可用状态。通过重调度，将实例分散部署于不同节点，若涉及 rack 层面，则分散部署于不同 rack，从而提高了服务的容灾能力。实践数据显示，该重调度策略可使高危服务的打散比例达到 95% 以上，显著增强了系统的可靠性和稳定性。

在过去的两年多时间里，重调度项目在字节跳动内部取得了显著成果，并已成功上线了字节跳动内部 90 多个集群，且在大多数集群中同时部署了 4 种以上的重调度策略。在此期间，从未因重调度操作引发任何稳定性事故，充分证明了该项目的可靠性与有效性。

未来规划

未来，Gödel Rescheduler 将继续拓展和优化：

• 更多重调度策略：引入更多实时数据，以丰富重调度策略的多样性。

• 稳定性建设：在优化调度效果的同时，持续降低重调度对集群稳定性的影响。

• 扩展性优化：进一步简化策略接入方式，提升插件化能力。

• 通用指标构建：制定通用的重调度评价指标，以全面评估重调度效果。

• 优化可解释性：增强重调度算法的可解释性，帮助用户更好地理解重调度决策的依据。

目前，Gödel Rescheduler 已经开源，地址：https://github.com/kubewharf/godel-rescheduler。欢迎大家关注并参与到项目建设中，无论是提出宝贵的建议，还是贡献代码和文档，都将为项目的发展注入新的活力。