【博客504】k8s Volcano资源调度算法与Gang Scheduling问题分析

k8s Volcano资源调度算法与Gang Scheduling问题分析

场景

k8s原生调度器在训练场景中的不足：

比如，某个大数据应用需要跑 1 个 Driver 容器+10 个 Executor 容器（对应 AI 训练的话，就是 1 个 PS 容器+10 个 Worker 容器）。如果容器是一个一个的调度，假设在启动最后一个 executor 容器（对应 AI 是 Worker 容器）时，由于资源不足而调度失败无法启动。那么前面的 9 个 executor 容器虽然运行着，其实也是浪费的。AI 训练也是一样的道理，必须所有的 Worker 都同时运行，才能进行训练，一个坏了，其他容器都等于白跑，而 GPU 被容器霸占着却不能开始计算，成本是非常高的。

k8s原生调度器的串行考虑：

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

k8s原生调度器的不足：

所以当总体资源需求小于集群资源时，普通的 K8s 自带调度器可以跑，没问题。但是当总体资源需求大于集群资源的时候，K8s 自带调度器会因为随机依次调度容器，使得部分容器无法调度，从而导致业务占着资源又不能开始计算，死锁着浪费资源。那么，上述两个场景哪一个更加常态呢？不用说，肯定是第二个，很少有企业可以大方到一直让集群空着，此时就需要增强型的 K8s 资源调度器 Volcano 了。

难点

资源调度领域

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

除了资源维度上的要求，实际调度中还有容灾和干扰隔离上的考虑：

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

Coscheduling和Gang scheduling

Wikipedia对 Coscheduling的定义：

在并发系统中将多个相关联的进程调度到不同处理器上同时运行的策略”。在Coscheduling的场景中，最主要的原则是保证所有相关联的进程能够同时启动。防止部分进程的异常，导致整个关联进程组的阻塞。这种导致阻塞的部分异常进程，称之为“碎片（fragement）”。

在Coscheduling的具体实现过程中，根据是否允许“碎片”存在，可以细分为：

Explicit Coscheduling
Local Coscheduling
Implicit Coscheduling。

其中Explicit Coscheduling就是大家常听到的Gang Scheduling。Gang Scheduling要求完全不允许有“碎片”存在， 也就是“All or Nothing”。

我们将上述定义的概念对应到Kubernetes中，就可以理解Kubernetes调度系统支持批任务Coscheduling的含义了。 一个批任务（关联进程组）包括了N个Pod（进程），Kubernetes调度器负责将这N个Pod调度到M个节点（处理器）上同时运行。如果这个批任务需要部分Pod同时启动即可运行，我们称需启动Pod的最小数量为min-available。特别地，当min-available=N时，批任务要求满足Gang Scheduling。

为什么Kubernetes调度系统需要Coscheduling？

Kubernetes目前已经广泛的应用于在线服务编排，为了提升集群的的利用率和运行效率，我们希望将Kubernetes作为一个统一的管理平台来管理在线服务和离线作业。默认的调度器是以Pod为调度单元进行依次调度，不会考虑Pod之间的相互关系。但是很多数据计算类的离线作业具有组合调度的特点，即要求所有的子任务都能够成功创建后，整个作业才能正常运行。如果只有部分子任务启动的话，启动的子任务将持续等待剩余的子任务被调度。这正是Gang Scheduling的场景。

如下图所示：

JobA需要4个Pod同时启动，才能正常运行。Kube-scheduler依次调度3个Pod并创建成功。到第4个Pod时，集群资源不足，则JobA的3个Pod处于空等的状态。但是它们已经占用了部分资源，如果第4个Pod不能及时启动的话，整个JobA无法成功运行，更糟糕的是导致集群资源浪费。

如果出现更坏的情况的话，如下图所示，集群其他的资源刚好被JobB的3个Pod所占用，同时在等待JobB的第4个Pod创建，此时整个集群就出现了死锁：

算法分析：

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

一、Gang Scheduling

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

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

二、DRF（dominant resource fairness）

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

三、Binpack

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

四、proportion（Queue 队列）

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

五、最终权重

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

社区相关的方案以及存在的风险

社区目前有Kube-batch以及基于Kube-batch衍生的Volcano 2个项目来解决上文中提到的痛点。实现的方式是通过开发新的调度器将Scheduler中的调度单元从Pod修改为PodGroup，以组的形式进行调度。使用方式是如果需要Coscheduling功能的Pod走新的调度器，其他的例如在线服务的Pod走Kube-scheduler进行调度。

这些方案虽然能够解决Coscheduling的问题，但是同样引入了新的问题。如大家所知，对于同一集群资源，调度器需要中心化。但如果同时存在两个调度器的话，有可能会出现决策冲突，例如分别将同一块资源分配给两个不同的Pod，导致某个Pod调度到节点后因为资源不足，导致无法创建的问题。解决的方式只能是通过标签的形式将节点强行的划分开来，或者部署多个集群。这种方式通过同一个Kubernetes集群来同时运行在线服务和离线作业，势必会导致整体集群资源的浪费以及运维成本的增加。再者，Volcano运行需要启动定制的MutatingAdmissionWebhook和ValidatingAdmissionWebhook。这些Webhooks本身存在单点风险，一旦出现故障，将影响集群内所有pod的创建。另外，多运行一套调度器，本身也会带来维护上的复杂性，以及与上游Kube-scheduler接口兼容上的不确定性。