为什么使用volcano？
原因如下：
- k8s原生的调度器仅支持顺序调度容器，即在需要多个容器配合的任务中，顺序调度容易造成容器死锁，更不用提其他的高级调度场景。
- 资源调度、容灾和干扰隔离：调度器需要在选出所有满足现有容器资源的node中挑选最合适的节点；同一应用或者有资源竞争的任务最好不要部署在同一个node中。
- 高级调度场景：Volcano提供了一组不同的调度算法，比如优先级、域资源公平性（DRF）和binpack。
Volcano
Volcano起源于kube-batch项目，这个项目最初的目的是解决Kubernetes中的分组调度问题。后来，随着AI和大数据服务开始要求Kubernetes更强大、更灵活的调度，kube-batch与各种场景特定的实践相结合，提供了增强的调度能力，后被重新命名为Volcano。下图是volcano的架构图：
可以看出，Volcano由scheduler、controllermanager、admission和vcctl组成:
-
scheduler通过一系列的action和plugin调度Job，并为它找到一个最适合的节点。与k8s本身的调度器相比，Volcano支持针对Job的多种调度算法。
-
controllermanager管理CRD资源的生命周期。它主要由Queue ControllerManager、PodGroupControllerManager 、 VCJob ControllerManager构成。
-
admission负责对CRD API资源进行校验。
-
vcctl是Volcano的命令行客户端工具。
本文主要讲解scheduler部分。
Volcano scheduler相关概念
Scheduler是负责Pod调度的组件，它由一系列action和plugin组成。action定义了调度各环节中需要执行的动作；plugin根据不同场景提供了action 中算法的具体实现细节。Volcano scheduler具有高度的可扩展性，我们可以根据需要实现自己的action和plugin。
上图为Volcano scheduler的工作流程，即：
- 当客户端提交的Job后，scheduler就会观察到并缓存起来，即将开启session。
- 开启session，即一个调度周期开始。
- 将没有被调度的Job发送到session的待调度队列中。
- 遍历所有的待调度Job，按照定义的次序依次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现。
- 关闭本次session。
volcano scheduler所有配置都在命名空间 volcano-system 下的 configmap volcano-scheduler-configmap 中配置。配置由两部分组成：actions和tiers。
action定义了调度流程，实现了主要的调度流程，在每个session中按顺序执行。在actions中，使用逗号作为分隔符配置各需要执行的action。action的配置顺序就是scheduler的执行顺序。Volcano本身不会对action顺序的合理性进行检查。
tiers中配置的plugin列表即为注册到scheduler中的plugin。plugin中 实现的算法将会被action调用。tiers 将plugin分为几类。plugin中定义的所有功能都将在session打开时进行注册，并在执行操作（action中使用）时调用。在某些情况下，用户可能会配置不同的plugin来注册相同的功能，将该需求在tiers中正确配置，如何组合这些功能将取决于业务需求。
在volcano中，action中有enqueue、allocate、preempt、reclaim、backfill、elect、reserve 7种内置的action，也可以自己开发其他的action，其中，enqueue和allocate是必须要有的。
下面将简单介绍一下各action的作用，详情请参见官网：volcano调度器介绍，以及代码中关于调度器的介绍。
- Enqueue action筛选符合要求的作业进入待调度队列。当一个Job下的最小资源申请量不能得到满足时，即使为Job下的Pod执行调度动作，Pod也会因为gang约束没有达到而无法进行调度；只有当job的最小资源量得到满足，状态由”Pending”刷新为”Inqueue”才可以进行。
- Allocate action是调度流程中的正常分配步骤，用于处理在待调度Pod列表中具有资源申请量的Pod调度，是调度过程必不可少的action。这个过程包括作业的predicate和prioritize。使用predicateFn预选，过滤掉不能分配作业的node；使用NodeOrderFn打分来找到最适合的分配节点。Allocate action遵循commit机制，当一个Pod的调度请求得到满足后，最终并不一定会为该Pod执行绑定动作，这一步骤还取决于Pod所在Job的gang约束是否得到满足。只有Pod所在Job的gang约束得到满足，Pod才可以被调度，否则，Pod不能够被调度。
- Preempt action是调度流程中的抢占步骤，用于处理高优先级调度问题。Preempt用于同一个Queue中job之间的抢占，或同一Job下Task之间的抢占。
- Reclaim action负责当一个新的任务进入待调度队列，但集群资源已不能满足该任务所在队列的要求时，根据队列权重回收队列应得资源。
- Reserve action从v1.2开始已经被弃用，并且被SLA plugin替代。Reserve action完成资源预留。将选中的目标作业与节点进行绑定。Reserve action、elect action 以及Reservation plugin组成了资源预留机制。Reserve action必须配置在allocate action之后。
- Backfill action是调度流程中的回填步骤，处理待调度Pod列表中没有指明资源申请量的Pod调度，在对单个Pod执行调度动作的时候，遍历所有的节点，只要节点满足了Pod的调度请求，就将Pod调度到这个节点上。
- Elect action 选择满足某些条件的作业。与作业的资源预留机制配合使用。在新版本中将不再使用。
plugins简要的信息可以查看官网和代码的文档，下图罗列了几个主要插件的函数和涉及资源：
下面是action中对插件注册函数的执行方式：
除了action和plugin，还需要了解 Queue、PodGroup 和 VolcanoJob，
在 Volcano 中，Queue 用于管理和优先级排序任务。它允许用户根据业务需求或优先级，将作业分组到不同的队列中。这有助于更好地控制资源分配和调度优先级，确保高优先级的任务可以优先获取资源。
PodGroup 一组相关的 Pod 集合。这主要解决了 Kubernetes 原生调度器中单个 Pod 调度的限制。通过将相关的 Pod 组织成 PodGroup，Volcano 能够更有效地处理那些需要多个 Pod 协同工作的复杂任务。
VolcanoJob 是 Volcano 中的一个核心概念，它扩展了 Kubernetes 的 Job 资源。VolcanoJob 不仅包括了 Kubernetes Job 的所有特性，还加入了对批处理作业的额外支持，使得 Volcano 能够更好地适应高性能和大规模计算任务的需求。
注意，kubenets和volcano里面的一些概念有有一些不同。Queue 是一个PodGroup队列，PodGroup是一组强关联的Pod集合。而 VolcanoJob是一个 K8s Job 升级版，对应的下一级资源是 PodGroup。换言之，就好比 ReplicaSet 的下一级资源是 Pod 一样。
所以 VolcanoJob 背后对应一个 K8s 里的自定义控制器（Operator 模式），这个控制器会根据 VolcanoJob 的具体配置去创建相应的 PodGroup 出来。而 PodGroup 最终会被当做一个整体被 Volcano Scheduler 调度。在调度的过程中，Volcano 还用到了 Queue 来实现 PodGroup 的排队、优先级控制等逻辑。
下一篇将会从action和plugins源码的角度分析volcano的Scheduler 。敬请期待！
