在今年的KubeCon峰会上海站，作为开源领域的贡献者和推进者，华为开源了面向高性能计算的云原生批量计算平台Volcano [vɒlˈkeɪnəʊ]。该项目基于华为云容器平台大规模高性能计算应用管理的最佳实践，在原生K8s的基础上，补齐了作业(Job)调度和设备管理等多方面的短板。目前，Volcano在华为云上对接了包括一站式AI开发平台ModelArts、云容器实例CCI、云容器引擎CCE在内的多款服务，是整个高性能计算领域不可或缺的基座。自开源以来，项目已经吸引了来自腾讯，百度，快手以及AWS等多个公司的贡献者。
随着容器化以及容器编排技术的普及，越来越多的上层业务正开始拥抱K8s生态，但无法否认的是，针对人工智能和大数据作业场景，原生K8s的支持度不高，终端用户如果想要将现有的业务迁移到K8s平台，很有可能会遇到下面的问题:
- 成组调度(Gang Scheduling)：一个BigData/AI的作业通常会包含多个任务，而业务逻辑一般要求Pod要么同时启动，要么不启动。比如，一个Tensorflow作业如果仅单独拉起一种角色的任务(Ps or Worker)是没法正常执行的。
- 资源公平调度(Fair-share)：部署的K8s集群会存在多个Namespace，而每个Namespace也可能提交多个作业，如何调度资源才能避免某个Namespace的资源被无限制压缩，又如何才能确保作业之间的资源调度公平？
- GPU Topology感知(GPU Topology Awareness)：一个常见的AI训练和推理作业，为了达到更高的性能，往往需要使用多个GPU共同完成，此时GPU的Topology结构以及设备之间的传输性能会对计算性能造成很大影响。目前, K8s提供的扩展资源调度机制还无法满足调度时Topology感知的问题。
- 集群自动配置(Cluster Configuration)：许多上层工具在业务启动之前，需要用户配置工具的集群状态，方便系统内部节点互通和识别，以MPI(Message Passing Interface)作业为例，需要用户以命令行参数“—host”配置集群的所有节点信息，并且还依赖节点之间SSH互通。所以，用户还要考虑怎样自动配置和管理业务集群。
此外，如何监控整个作业集群的状态？单个Pod失败如何处理？怎么解决任务依赖的问题等，都是需要处理的问题。
基于此，Volcano在解决此类问题的基础上提供了一个针对BigData和AI场景下，通用、可扩展、高性能、稳定的原生批量计算平台，方便以Kubeflow、KubeGene、Spark为代表的上层业务组件集成和使用。
概述
如图2所示，Volcano在K8s之上抽象了一个批量计算的通用基础层，向下弥补K8s调度能力的不足，向上提供灵活通用的Job抽象。目前，该项目最重要的两个组件分别是Volcano-Scheduler和Volcano-Controller。
Volcano-Scheduler：这个组件最开始来自社区的Scheduling SIG子项目项目Kube-Batch， 是一个可扩展的增强调度器，主要支持的能力有：
Actions:
- Allocate: 正常的资源分配动作。
- Preempt: 抢占，当系统中存在高优先级作业，且系统资源无法满足请求时，会触发资源抢占操作。
- Reclaim: 资源回收, Kube-Batch会使用队列(queue)将资源按照比例分配，当系统中新增或移除队列时，Reclaim会负责回收和重新分配资源到剩余队列中去。
Plugins:
- DRF: 即Domaint Resource Fairness, 目的是为了确保在多种类型资源共存的环境下，尽可能满足分配的公平原则，其理论最早来自于UC伯克利大学的论文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》[5]。
- Conformance: 资源一致性，确保系统关键资源不被强制回收使用。
- Gang: 资源成组,确保作业内的成组Pod资源不被强制驱逐。
而Volcano-Scheduler在Kube-Batch的基础上又更进一步，引入了更多领域性的动作和插件，包括BinPack、GPUShare、GPUTopoAware等。
Volcano-Controller：Volcano通过CRD的方式提供了通用灵活的Job抽象Volcano Job (batch.volcano.sh/jobs)，Controller则负责与Scheduler配合，管理Job的整个生命周期。主要功能包括:
- 自定义的Job资源: 跟K8s内置的Job(作业)资源相比，Volcano Job有了更多增强配置，比如: 任务配置，提交重试，最小调度资源数，作业优先级, 资源队列等。
- Job生命周期管理: Volcano Controller会监控Job的创建，创建和管理对应的子资源(Pod, ConfigMap, Service)，刷新作业的进度概要，提供CLI方便用户查看和管理作业资源等。
- 任务执行策略: 单个Job下面往往会关联多个任务(Task)，而且任务之间可能存在相互依赖关系，Volcano Controller支持配置任务策略，方便异常情况下的任务间关联性重试或终止。
- 扩展插件: 在提交作业、创建Pod等多个阶段，Controller支持配置插件用来执行自定义的环境准备和清理的工作，比如常见的MPI作业，在提交前就需要配置SSH插件，用来完成Pod资源的SSH信息配置。
下面以一个MPI Job作业的YAML片段为例，带大家从整体上了解Job Controller的功能(扩展功能相关字段已添加注释，方便理解)。
有了上面的介绍，回过头来参照图5梳理Volcano一次普通作业的执行流程也就很容易理解了。
-
用户通过kubectl创建Volcano Job资源。
-
Volcano Controller监测到Job资源创建，校验资源有效性，依据JobSpec创建依赖的Pod， Service， ConfigMap等资源，执行配置的插件。
-
Volcano Scheduler监听Pod资源的创建，依据策略，完成Pod资源的调度和绑定。
-
Kubelet负责Pod资源的创建，业务开始执行。
-
Volcano Controller负责Job后续的生命周期管理(状态监控，事件响应，资源清理等)。
调度效率
除去易用性和扩展性，在BigData和AI场景下，资源调度的效率(成功率)通常能有效减少业务的运行时间，提高底层硬件设备的使用率，从而降低使用成本，我们以Volcano Scheduler和原生Scheduler在Gang Scheduling的场景下做了一个简单的TF Job 执行时间对比:
参考图6发现，单个作业的执行环境，两种执行方式在运行时间上并无明显区别，但是当集群中存在多个作业时，因为原生Scheduler无法保证调度的成组性，直接导致极端的情况出现: 作业之间出现资源竞争，互相等待，上层业务无法正常运行，直至超时，此时的调度效率大打折扣。
社区和贡献
Volcano项目目前还在不断的发展壮大中，更多特性也在设计和开发阶段，如果广大开发者有兴趣，欢迎随时加入Slack讨论，提问题给意见或者贡献代码。