Kubernetes 调度器优化

作为 kubernetes 集群的默认调度器，kube-scheduler 主要负责将 Pod 调度到集群的 Node 上。在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 可调度 Node。调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 绑定。

这篇文章将会介绍一些在大规模 Kubernetes 集群下调度器性能优化的方式。

在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。

你可以通过设置 kube-scheduler 的 percentageOfNodesToScore 来配置这个调优设置。这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。设置阈值

percentageOfNodesToScore 选项接受从 0 到 100 之间的整数值。0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。如果你设置 percentageOfNodesToScore 的值超过了 100，kube-scheduler 的表现等价于设置值为 100。

要修改这个值，编辑 kube-scheduler 的配置文件（通常是 /etc/kubernetes/config/kube-scheduler.yaml），然后重启调度器。

修改完成后，你可以执行

kubectl get componentstatuses

来检查该 kube-scheduler 组件是否健康。输出类似如下：

NAME                 STATUS    MESSAGE             ERRORcontroller-manager   Healthy   okscheduler            Healthy   ok...

节点打分阈值

要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。

你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，kube-scheduler 将停止继续查找可调度节点并继续进行 打分阶段。

调度器如何遍历节点 详细介绍了这个过程。默认阈值

如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-node 集群下取 50%，在 5000-node 的集群下取 10%。这个自动设置的参数的最低值是 5%。

这意味着，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。

如果你想让调度器对集群内所有节点进行打分，则将 percentageOfNodesToScore 设置为 100。示例

下面就是一个将 percentageOfNodesToScore 参数设置为 50% 的例子。

apiVersion: kubescheduler.config.k8s.io/v1alpha1kind: KubeSchedulerConfigurationalgorithmSource:  provider: DefaultProvider ... percentageOfNodesToScore: 50

调节 percentageOfNodesToScore 参数

percentageOfNodesToScore 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的。另外，还有一个 50 个 Node 的最小值是硬编码在程序中。

注意： 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。同理，在小规模集群中，如果你将 percentageOfNodesToScore 设置为一个较低的值，则没有或者只有很小的效果。如果集群只有几百个节点或者更少，请保持这个配置的默认值。改变基本不会对调度器的性能有明显的提升。

值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 node 都没有进入到打分阶段。这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。

由于这个原因，这个参数不应该被设置成一个很低的值。通常的做法是不会将这个参数的值设置的低于 10。很低的参数值一般在调度器的吞吐量很高且对 node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。调度器做调度选择的时候如何覆盖所有的 Node

如果你想要理解这一个特性的内部细节，那么请仔细阅读这一章节。

在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 percentageOfNodesToScore 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。

如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：

Zone 1: Node 1, Node 2, Node 3, Node 4Zone 2: Node 5, Node 6

调度器将会按照如下的顺序去评估 Node 的可调度性：

Node 1, Node 5, Node 2, Node 6, Node 3, Node 4

在评估完所有 Node 后，将会返回到 Node 1，从头开始。

调度系统的本质是为计算服务或任务匹配合适的资源，使其能够稳定高效地运行，以及在此基础上进一步提高资源使用密度，而影响应用运行的因素非常多，比如 CPU、内存、IO、差异化的资源设备等一系列因素都会影响应用运行的表现。同时，单独和整体的资源请求、硬件 / 软件 / 策略限制、 亲和性要求、数据区域、负载间的干扰等因素以及周期性流量场景、计算密集场景、在离线混合等不同应用场景的交织也带来了决策上的很多变化。

调度器的目标则是快速准确地实现这一能力，但快速和准确这两个目标在资源有限的场景下往往会产生矛盾，这需要在二者间权衡，本文主要分享了作业帮在实际应用 K8s 过程中遇到的问题以及最终探讨出的解决方案，希望对广大开发者有所帮助。

1、调度器原理和设计

K8s 默认调度器的整体工作框架可以简单用下图概括：

两个控制循环

1、第一个控制循环称为 Informer Path，主要工作是启动一系列 Informer，用来监听（Watch）集群中 Pod、Node、Service 等与调度相关的 API 对象的变化。比如，当一个待调度 Pod 被创建出来之后，调度器就会通过 Pod Informer 的 Handler，将这个待调度 Pod 添加进调度队列；同时，调度器还要负责对调度器缓存 Scheduler Cache 进行更新，并以这个 cache 为参考信息，来提高整个调度流程的性能。

2、第二个控制循环即为对 pod 进行调度的主循环，称为 Scheduling Path。这一循环的工作流程是不断地从调度队列中取出待调度的 pod，运行两个步骤的算法，来选出最优 node

• 在集群的所有节点中选出所有“可以”运行该 pod 的节点，这一步被称为 Predicates；

• 在上一步选出的节点中，根据一系列优选算法对节点打分，选出“最优”即得分最高的节点，这一步被称为 Priorities。

调度完成之后，调度器就会为 pod 的 spec.NodeName 赋值这个节点，这一步称为 Bind。而为了不在主流程路径中访问 Api Server 影响性能，调度器只会更新 Scheduler Cache 中的相关 pod 和 node 信息：这种基于乐观假设的 API 对象更新方式，在 K8s 中称为 Assume。之后才会创建一个 goroutine 来异步地向 API Server 发起更新 Bind 操作，这一步就算失败了也没有关系，Scheduler Cache 更新后就会一切正常。

2、大规模集群调度带来的问题和挑战

K8s 默认调度器策略在小规模集群下有着优异表现，但是随着业务量级的增加以及业务种类的多样性变化，默认调度策略则逐渐显露出局限性：调度维度较少，无并发，存在性能瓶颈，以及调度器越来越复杂。

迄今为止，我们当前单个集群规模节点量千级，pod 量级则在 10w 以上，整体资源分配率超过 60%，其中更是包含了 GPU、在离线混合部署等复杂场景。在这个过程中，我们遇到了不少调度方面的问题。

问题 1：高峰期的节点负载不均匀

默认调度器，参考的是 workload 的 request 值，如果我们针对 request 设置的过高，会带来资源浪费；过低则有可能带来高峰期 CPU 不均衡差异严重的情况；使用亲和策略虽然可以一定程度避免这种，但是需要频繁填充大量的策略，维护成本就会非常大。而且服务的 request 往往不能体现服务真实的负载，带来差异误差。而这种差异误差，会在高峰时体现到节点负载不均上。

实时调度器，在调度的时候获取各节点实时数据来参与节点打分，但是实际上实时调度在很多场景并不适用，尤其是对于具备明显规律性的业务来说，比如我们大部分服务晚高峰流量是平时流量的几十倍，高低峰资源使用差距巨大，而业务发版一般选择低峰发版，采用实时调度器，往往发版的时候比较均衡，到晚高峰就出现节点间巨大差异，很多实时调度器往往在出现巨大差异的时候会使用再平衡策略来重新调度，高峰时段对服务 POD 进行迁移，服务高可用角度来考虑是不现实的。显然，实时调度是远远无法满足业务场景的。

我们的方案：高峰预测时调度

针对这种情况，需要预测性调度方案，根据以往高峰时候 CPU、IO、网络、日志等资源的使用量，通过对服务在节点上进行最优排列组合回归测算，得到各个服务和资源的权重系数，基于资源的权重打分扩展，也就是使用过去高峰数据来预测未来高峰节点服务使用量，从而干预调度节点打分结果。

问题 2：调度维度多样化

随着业务越来越多样，需要加入更多的调度维度，比如日志。由于采集器不可能无限速率采集日志且日志采集是基于节点维度。需要平衡日志采集速率，各个节点差异不可过大。部分服务 CPU 使用量一般但是日志输出量很大，而日志并不属于默认调度器决策的一环，所以当这些日志量很大的多个服务 pod 在同一个节点上时，该机器上的日志上报就有可能出现部分延迟。

我们的方案：补全调度决策因子

该问题显然需要对调度决策补全，我们扩展了预测调度打分策略，添加了日志的决策因子，将日志也作为节点的一种资源，并根据历史监控获取到服务对应的日志使用量来计算分数。

问题 3：大批量服务扩缩带来的调度时延

随着业务复杂度进一步上升，在高峰时段出现，会有大量定时任务和集中大量弹性扩缩，大批量（上千 POD）同时调度导致调度时延上涨，这两者对调度时间比较敏感，尤其对于定时任务来说，调度延时的上涨会被明显感知到，原因是 K8s 调度 pod 本身是对集群资源的分配，反应在调度流程上则是预选和打分阶段是顺序进行的。如此一来，当集群规模大到一定程度时，大批量更新就会出现可感知的 pod 调度延迟。

我们的方案：拆分任务调度器，加大并发调度域、批量调度

解决吞吐能力低下最直接的方法就是串行改并行，对于资源抢占场景，尽量细化资源域，资源域之间并行。基于以上策略，我们拆分出了独立的 Job 调度器，同时使用 Serverless 作为 Job 运行的底层资源。K8s Serverless 为每一个 Job POD 单独申请了独立的 POD 运行 sanbox，也就是任务调度器，完整并行。以下为对比图：

原生调度器在晚高峰下节点 CPU 使用率

优化后调度器在晚高峰下节点 CPU 使用率

3、总结

Work 节点资源、GPU 资源、Serverless 资源是我们集群异构资源的三类资源域，这三种资源上运行的服务存在天然差异，我们使用 forecast-scheduler、gpu-scheduler、job-schedule 三个调度器来管理这三种资源域上的 Pod 调度情况。

• 预测调度器管理大部分在线业务，其中扩展了资源维度，添加了预测打分策略。

• GPU 调度器管理 GPU 资源机器的分配，运行在线推理和离线训练，两者的比例处于长期波动中，高峰期间离线训练缩容、在线推理扩容；非高峰期间离线训练扩容、在线推理缩容；同时处理一些离线图片任务来复用 GPU 机器上比较空闲的 CPU 等资源。

• Job 调度器负责管理定时任务调度，定时任务量大且创建销毁频繁，资源使用非常碎片化，而且对时效性要求更高；所以我们将任务尽量调度到 Serverless 服务上，压缩集群中为了能容纳大量任务而冗余的机器资源，提升资源利用率。

4、未来演进探讨

• 更细粒度的资源域划分，将资源域划分至节点级别，节点级别加锁来进行。

• 资源抢占和重调度。正常场景下，当一个 Pod 调度失败，这个 Pod 会保持在 pending 的状态，等待 Pod 更新或者集群资源发生变化进行重新调度，但是 K8s 调度器依然存在一个抢占功能，可以使得高优先级 Pod 在调度失败时，挤走某个节点上的部分低优先级 Pod 以保证高优先级 Pod 的正常运行，迄今为止我们并没有使用调度器的抢占能力，即使我们通过以上多种策略来加强调度的准确性，但依然无法避免部分场景下由于业务带来的不均衡情况，这种非正常场景中，重调度的能力就有了用武之地，也许重调度将会成为日后针对异常场景的一种自动修复方式。