Crane-scheduler：基于真实负载进行调度

作者

邱天，腾讯云高级工程师，负责腾讯云 TKE 动态调度器与重调度器产品。

背景

原生 kubernetes 调度器只能基于资源的 resource request 进行调度，然而 Pod 的真实资源使用率，往往与其所申请资源的 request/limit 差异很大，这直接导致了集群负载不均的问题：

1. 集群中的部分节点，资源的真实使用率远低于 resource request，却没有被调度更多的 Pod，这造成了比较大的资源浪费；

2. 而集群中的另外一些节点，其资源的真实使用率事实上已经过载，却无法为调度器所感知到，这极大可能影响到业务的稳定性。

这些无疑都与企业上云的最初目的相悖，为业务投入了足够的资源，却没有达到理想的效果。

既然问题的根源在于 resource request 与真实使用率之间的「鸿沟」，那为什么不能让调度器直接基于真实使用率进行调度呢？这就是 Crane-scheduler 设计的初衷。Crane-scheduler 基于集群的真实负载数据构造了一个简单却有效的模型，作用于调度过程中的 Filter 与 Score 阶段，并提供了一种灵活的调度策略配置方式，从而有效缓解了 kubernetes 集群中各种资源的负载不均问题。换句话说，Crane-scheduler 着力于调度层面，让集群资源使用最大化的同时排除了稳定性的后顾之忧，真正实现「降本增效」。

整体架构

如上图所示，Crane-scheduler 依赖于 Node-exporter 与 Prometheus 两个组件，前者从节点收集负载数据，后者则对数据进行聚合。而 Crane-scheduler 本身也包含两个部分:

1. Scheduler-Controller 周期性地从 Prometheus 拉取各个节点的真实负载数据， 再以 Annotation 的形式标记在各个节点上；

2. Scheduler 则直接在从候选节点的 Annotation 读取负载信息，并基于这些负载信息在 Filter 阶段对节点进行过滤以及在 Score 阶段对节点进行打分；

基于上述架构，最终实现了基于真实负载对 Pod 进行有效调度。

调度策略

下图是官方提供的 Pod 的调度上下文以及调度框架公开的扩展点：