作业帮 Kubernetes 原生调度器优化实践.docxVIP

作业帮 Kubernetes 原生调度器优化实践 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 更新后就会一切正常。 大规模集群调度带来的问题和挑战 K8s 默认调度器策略在小规模集群下有着优良表现，但是随着业务量级的添加以及业务品种的多样性变化，默认调度策略则渐渐显显露局限性：调度维度较少，无并发，存在功能瓶颈，以及调度器越来越简单。 迄今为止，我们当前单个集群规模节点量千级，pod 量级则在 10w 以上，全体资源安排率超过 60%，其中更是包含了 GPU、在离线混合部署等简单场景。在这个过程中，我们遇到了不少调度方面的问题。 问题 1：高峰期的节点负载不均匀 默认调度器，参考的是 workload 的 request 值，假如我们针对 request 设置的过高，会带来资源铺张；过低则有可能带来高峰期 CPU 不均衡差异严峻的情况；使用亲和策略虽然可以肯定程度避开这种，但是需要频繁填充大量的策略，维护成本就会格外大。而且服务的 request 往往不能体现服务真实的负载，带来差异误差。而这种差异误差，会在高峰时体现到节点负载不均上。 实时调度器，在调度的时候猎取各节点实时数据来参与节点打分，但是实际上实时调度在很多场景并不适用，尤其是对于具备明显规律性的业务来说，比如我们大部分服务晚高峰流量是平常流量的几十倍，凹凸峰资源使用差距巨大，而业务发版一般选择低峰发版，接受实时调度器，往往发版的时候比较均衡，到晚高峰就消灭节点间巨大差异，很多实时调度器往往在消灭巨大差异的时候会使用再平衡策略来重新调度，高峰时段对服务 POD 进行迁移，服务高可用角度来考虑是不现实的。明显，实时调度是远远无法满足业务场景的。 我们的方案：高峰猜测时调度 针对这种情况，需要猜测性调度方案，依据以往高峰时候 CPU、IO、网络、日志等资源的使用量，通过对服务在节点上进行最优陈列组合回归测算，得到各个服务和资源的权重系数，基于资源的权重打分扩展，也就是使用过去高峰数据来猜测将来高峰节点服务使用量，从而干涉调度节点打分结果。 问题 2：调度维度多样化 随着业务越来越多样，需要加入更多的调度维度，比如日志。由于采集器不行能无限速率采集日志且日志采集是基于节点维度。需要平衡日志采集速率，各个节点差异不行过大。部分服务 CPU 使用量一般但是日志输出量很大，而日志并不属于默认调度器决策的一环，所以当这些日志量很大的多个服务 pod 在同一个节点上时，该机器上的日志上报就有可能消灭部分延迟。 我们的方案：补全调度决策因子 该问题明显需要对调度决策补全，我们扩展了猜测调度打分策略，添加了日志的决策因子，将日志也作为节点的一种资源，并依据历史监控猎取到服务对应的日志使用量来计算分数。 问题 3：大批量服务扩缩带来的调度时延 随着业务简单度进一步上升，在高峰时段消灭，会有大量定时任务和集中大量弹性扩缩，大批量（上千 POD）同时调度导致调度时延上涨，这两者对调度时间比较敏感，尤其对于定时任务来说，调度延时的上涨会被明显感知到，缘由是 K8s 调度 pod 本身是对集群资源的安排，反应在调度流程上则是预选和打