为什么 K8s 需要 Volcano？

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

为什么 K8s 需要 Volcano

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

比如，某个大数据应用需要跑 1 个 Driver 容器+10 个 Executor 容器（对应 AI 训练的话，就是 1 个 PS 容器+10 个 Worker 容器）。如果容器是一个一个的调度，假设在启动最后一个 executor 容器（对应 AI 是 Worker 容器）时，由于资源不足而调度失败无法启动，那么前面的 9 个 executor 容器虽然运行着，其实也是浪费的。

AI 训练也是一样的道理，必须所有的 Worker 同时运行，才能进行训练，坏一个，其他的容器就等于白跑。而 GPU 被容器霸占着却不能开始计算，成本是非常高的。

所以当你的（1）总体资源需求<集群资源的时候，普通的 K8s 自带调度器可以跑，没问题。但是当（2）总体资源需求>集群资源的时候，K8s 自带调度器会因为随机依次调度容器，使得部分容器无法调度，从而导致业务占着资源又不能开始计算，死锁着浪费资源。那么场景（1）和场景（2）谁说常态呢？不用说，肯定是（2）了，谁能大方到一直让集群空着呢对吧。这种情况就必须需要增强型的 K8s 资源调度器 Volcano 了。

资源调度领域

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

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

算法分析

Volcano 首先要解决的问题就是 Gang Scheduling 的问题，即一组容器要么都成功，要么都别调度。这是最基本的用来解决资源死锁的问题，可以很好提高集群资源利用率（在高业务负载时）。

除此之外，它还提供了多种调度算法，例如 priority 优先级，DRF（dominant resource fairness）， binpack 等。 我们今天就是挖一挖 Volcano 内部的各种调度算法实现。

3.1 Gang Scheduling

这种调度算法，首先是有’组’的概念，调度结果成功与否，只关注整一’组’容器。

具体算法是，先遍历各个容器组（代码里面称为 Job），然后模拟调度这一组容器中的每个容器（代码里面称为 Task）。最后判断这一组容器可调度容器数是否大于最小能接受底限，可以的话就真的往节点调度（代码里面称为 Bind 节点）。

3.2 DRF（dominant resource fairness）

这种调度算法，主要是 Yarn 和 Mesos 都有，而 K8s 没有，需要补齐。概括而言，DRF 意为：“谁要的资源少，谁的优先级高”。这样可以满足更多的作业，不会因为一个胖业务，饿死大批小业务。注意：这个算法选的也是容器组（比如一次 AI 训练，或一次大数据计算）。

3.3 binpack

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

3.4 proportion（Queue 队列）

Queue 功能是 Yarn 调度器有的功能，K8s 需要补齐。不过我对 Queue 这个取名有些不太满意。因为它实际是用来控制集群总资源分配比例的。比如某厂有 2 个团队，共享一个计算资源池。管理员设置：A 团队最多使用总集群的 60%，B 团队最多使用总集群的 40%。投递的任务量，超过该团队的可用资源怎么办？那就排队等呗，所以特性取名 Queue。

3.5 最终权重

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

Volcano

Volcano 项目的前身是 Kube-Batch，一个带着想解决 K8s 不支持 Gang Scheduling 问题初衷的项目。后来由于 AI 和大数据等业务领域也开始对 K8s 有述求，团队成员希望有一种喷薄而出的感觉，所以带上具体场景实践经验，重新将项目命名为 Volcano–火山，希望能够推动 K8s 在各个场景下向火山一样热烈绽放。

项目地址

添加小助手微信，加入【容器魔方】技术社群。