调度系统的本质是为计算服务/任务匹配合适的资源，使其能够稳定高效地运行，以及在此的基础上进一步提高资源使用密度，而影响应用运行的因素非常多，比如CPU、内存、io、差异化的资源设备等等一系列因素都会影响应用运行的表现。同时，单独和整体的资源请求、硬件/软件/策略限制、 亲和性要求、数据区域、负载间的干扰等因素以及周期性流量场景、计算密集场景、在离线混合等不同的应用场景的交织也带来了决策上的多变。
调度器的目标则是快速准确地实现这一能力，但快速和准确这两个目标在资源有限的场景下会往往产生产生矛盾，需要在二者间权衡。
调度器原理和设计
k8s默认调度器的整体工作框架，可以简单用下图概括：
两个控制循环
1. 第一个控制循环，称为 Informer Path。它的主要工作，是启动一系列的 Informer，用来监听（Watch）集群中 Pod、Node、Service 等与调度相关的 API 对象的变化。比如，当一个待调度 Pod被创建出来之后，调度器就会通过 Pod Informer 的 Handler，将这个待调度 Pod 添加进调度队列；同时，调度器还要负责对调度器缓存Scheduler Cache进行更新，并以这个cache为参考信息，来提高整个调度流程的性能。
2. 第二个控制循环，即为对pod进行调度的主循环，称为Scheduling Path。这一循环的工作流程是不断地从调度队列中取出待调度的pod，运行2个步骤的算法，来选出最优node
1. 在集群的所有节点中，选出所有“可以”运行该pod的节点，这一步被称为Predicates。
2. 在上一步选出的节点中，根据一些列优选算法对节点就行打分，选出“最优”即得分最高的节点，这一步被称为Priorities。
调度完成之后，调度器就会为pod的spec.NodeName赋值这个节点，这一步称为Bind。而为了不在主流程路径中访问Api Server影响性能，调度器只会更新Scheduler Cache中的相关pod和node信息：这种基于乐观的假设的Api对象更新方式，在k8s中称为Assume。之后才会创建一个goroutine来异步地向Api Server发起更新Bind操作，这一步就算失败了也没有关系，Scheduler Cache更新后就会一切正常。
大规模集群调度带来的问题和挑战
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使用率
总结
work节点资源、gpu资源、serverless资源这就是我们集群异构资源分属于这三类资源域，这三种资源上运行的服务存在天然的差异性，我们使用forecast-scheduler、gpu-scheduler、job-schedule 三个调度器来管理这三种资源域上的pod的调度情况。
预测调度器管理大部分在线业务，其中扩展了资源维度，添加了预测打分策略。
gpu调度器管理gpu资源机器的分配，运行在线推理和离线训练，两者的比例处于长期波动中，高峰期间离线训练缩容、在线推理扩容；非高峰期间离线训练扩容、在线推理缩容；同时处理一些离线图片处理任务来复用gpu机器上比较空闲的cpu等资源。
job调度器负责管理我们定时任务的调度，定时任务量大且创建销毁频繁，资源使用非常碎片化，而且对实效性要求更高；所以我们将任务尽量调度到serverless服务上，压缩集群中为了能容纳大量的任务而冗余的机器资源，提升资源利用率。
未来的演进探讨
更细粒度的资源域划分
将资源域划分至节点级别，节点级别加锁来进行
资源抢占和重调度
正常场景下，当一个pod调度失败的时候，这个pod会保持在pending的状态，等待pod更新或者集群资源发生变化进行重新调度，但是k8s调度器依然存在一个抢占功能，可以使得高优先级pod在调度失败的时候，挤走某个节点上的部分低优先级pod以保证高优pod的正常，迄今为止我们并没有使用调度器的抢占能力，即使我们通过以上多种策略来加强调度的准确性，但依然无法避免部分场景下由于业务带来的不均衡情况，这种非正常场景中，重调度的能力就有了用武之地，也许重调度将会成为日后针对异常场景的一种自动修复的方式。
正常场景下，当一个pod调度失败的时候，这个pod会保持在pending的状态，等待pod更新或者集群资源发生变化进行重新调度，但是k8s调度器依然存在一个抢占功能，可以使得高优先级pod在调度失败的时候，挤走某个节点上的部分低优先级pod以保证高优pod的正常，迄今为止我们并没有使用调度器的抢占能力，即使我们通过以上多种策略来加强调度的准确性，但依然无法避免部分场景下由于业务带来的不均衡情况，这种非正常场景中，重调度的能力就有了用武之地，也许重调度将会成为日后针对异常场景的一种自动修复的方式。
