Kubernetes增强型调度器Volcano（适配大数据调度）

Volcano调度器背景

    Volcano是基于Kubernetes的批处理系统，为华为开源。Volcano方便AI、大数据、基因、渲染等诸多行业通用计算框架接入，提供高性能任务调度引擎，高性能异构芯片管理，高性能任务运行管理等能力。

    Volcano调度的意义

    K8s自带的资源调度器，有一个明显的特点：依次调度每个容器。但是在AI训练或者大数据，这种必须多个容器同时配合执行的情况下，容器依次调度是无法满足需要的。因为这些计算任务包含的容器需求是要么同时成功，要么就全部都不执行。

    例如，某个大数据应用需要跑1个Driver容器+10个Executor容器。如果容器是一个个调度，假设在启动最后一个executor容器时，由于资源不足而调度失败无法启动时，那么前面的9个Executor容器虽然运行着，但是没有实际的成效，相当于一种资源的浪费。在AI训练中同样也是所有的容器必须同时运行，才能进行训练。如果当中一个出现问题就相当于白跑。

    故而出现如下情景：总体资源需求<集群资源的时候，普通的K8s自带调度器可以运行，当总体资源小于集群资源需求的时候，K8s自带调度器会依次调度容器，那么就有部分容器无法调度，占着容器的资源，造成资源的死锁现象出现，要避免这种情况的出现就得引入增强型的K8s资源调度器。

 

    资源调度领域

    当用户向K8s申请容器所需要的计算资源（CPU、MeM、GPU），调度器负责挑选出满足各项规格要求的节点来部署这些容器。通常，满足各项要求的节点并非唯一，且水位（节点已有负载）各不相同，不同的分配方式最终得到的分配率存在差异，因此，调度器的一项核心任务就是以最终资源利用率最优的目标从众多候选机器中挑出最合适的节点。

除了资源纬度上的要求，实际调度中还有容灾和干扰隔离上的考虑，比如同一应用的容器不允许全部部署到同一台节点上，很多应用会要求每台节点上只允许有一个实例。另外，某些应用组件之间还存在互斥关系（如资源争抢），严重影响应用的性能，因此也不允许它们被部署到同一台节点上。这些限制条件的引入，使得想新写一款调度器，能替代原生K8S调度器并不容易。

 

volcano算法分析

volcano首先要解决的问题就是Gang Scheduling的问题，即一组容器要么都成功，要么都别调度；这个是最基本的用来解决资源死锁的问题，可以很好的提高集群资源利用率（在高业务负载时）。除此之外，它还提供了多种调度算法，例如priority优先级，DRF（dominant resource fairness）， binpack等。 我们今天就是挖一挖Volcano内部的各种调度算法实现。

1.1 Gang Scheduling

这种调度算法，首先就是有’组’的概念，调度结果成功与否，只关注整一’组’容器。具体算法：先遍历各个容器组（job）， 然后模拟调度这一组容器中的每个容器（Task）。最后判断这一组容器可调度容器数是否大于最小能接受底限，可以的话就真实的往节点上调度。

 

 

1.2 DRF（dominant resource fairness）

DRF意为：“谁要的资源少，谁的优先级高”。因为这样可以满足更多的作业，不会因为一个胖业务，饿死大批小业务。注意：这个算法选的也是容器组（比如一次AI训练，或一次大数据计算）。

1.3 binpack

这种调度算法，目标很简单：尽量先把已有节点填满（尽量不往空白节点投）。具体实现上，binpack就是给各个可以投递的节点打分：“假如放在当前节点后，谁更满，谁的分数就高”。因为这样可以尽量将应用负载靠拢至部分节点，非常有利于K8S集群节点的自动扩缩容功能。注意：这个算法是针对单个容器的。

1.4 Proportion（Queue队列）

用来控制集群总资源分配比例的。比如说某厂有2个团队，共享一个计算资源池。管理员设置：A团队最多使用总集群的60%。然后B团队最多使用总集群的40%。那投递的任务量，超过该团队的可用资源怎么办？那就排队等呗，所以特性取名Queue。

 

1.5最终权重

由于Volcano的调度算法插件实在太多，每个插件的决策又有可能互相干扰。所以为了在各个算法间做权衡，又给插件设置了权重，这样可以控制每种调度算法插件的影响因子。比如NodeOrder算法里面，就是在优选阶段（注：k8s调度，分预选阶段和优选阶段。预选就是排除不符合的节点。优选就是给所有符合的节点打分）给节点打分的算法。各个算法有自己的权重可以配置。

 

volcano地址： https://volcano.sh/