Volcano 是一个基于 Kubernetes 的云原生批量计算平台，也是 CNCF 的首个容器批量计算项目，主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。它提供面向高性能负载的调度策略、完善的作业生命周期管理、异构硬件管理、面向高性能负载的性能优化等能力，目前在很多领域都已落地应用。
目前 Volcano 已经支持几乎所有的主流计算框架，包括 MindSpore、TensorFlow、Kubeflow、MPI、PyTorch、飞桨、Spark、Flink、HOROVOD 等。
01JobFlow诞生的背景
Volcano 虽然提供了优秀的基于作业的任务编排功能，但缺乏作业间的编排能力。业界在需要作业编排时，通常的解决方式有以下几种：
人工手动提交多个作业。该流程操作繁琐，重复操作多，时效性差，时间成本通常很高。
结合已有的作业平台完成。通常企业、单位内部都有一套作业平台，作业编排可以在该平台上完成用以满足自身需求。但该方案缺乏通用性，对缺失作业平台的用户也不友好。
结合 Argo Workflow 完成。Argo Workflow 是一款优秀的开源云原生工作流引擎，在 K8S 之上编排并行作业。使用 Argo 对 Volcano 作业进行编排时，采用 resources 的模板类型来引入 vcjob 。workflow 提供了 STEP 与 DAG 两种这种方式来处理依赖结构的关系，这两种方式几乎涵盖了所有的复杂依赖结构，对于任务的串行并行都可以支持。但在依赖类型方面只提供了任务的完成、失败、出错等通用结果。在状态信息方面也趋向更加通用的结果。在对 vcjob 的任务编排时，用户可能依赖任务 running 状态，或者是探针的形式。此时 workflow 这种通用情况的作业编排将不再适用。另外，workflow 可以查看到 vcjob 级别的进度（完成与未完成），但不能直观的展示 vcjob 下任务及 pod 的完成情况，与对应的状态信息等。
以上方案都较为复杂，在作业流编排上步骤繁琐、外部依赖较为严重。一款云原生的高性能计算作业流引擎就显得十分重要。
02JobFlow 对作业流编排的支持能力
为了解决上述问题，博云高性能计算团队设计并提出了 JobFlow 项目，专注于对多作业场景下的调度管理，可以实时查看作业及其任务的完成进度、执行状态，只要资源允许的场景下，自动下发后续任务，大大提升了资源利用率、减少了人工成本和作业执行时间。
JobFlow 的完整运行包含了 JobFlow 和 JobTemplate 。其中 JobFlow 用于描述作业之间的依赖关系，并跟踪作业下发以及运行过程的相关状态信息。JobTemplate 是用于描述作业各项信息的模板，用户可以基于模板分批次创建多个作业并运行。JobFlow 于 JobTemplate 关系如下图：
当采用 JobFlow 后，用户对多作业的编排流程会大大缩减，仅需定义作业模板及作业间的依赖关系即可。为了减少迁移成本，JobFlow 项目同时提供了标准工具用于将现有的作业转化为作业模板。该工具也支持反向操作，即随时根据作业模板的定义启动一个作业并运行。当定义好模板及作业依赖后，用户可以采用 K8S 原生的方式去跟踪多个作业的执行状态、执行时长、作业结果等常见信息。
当前 JobFlow 中的作业依赖关系还比较简单，支持了出现最多的场景，即在前序作业执行结束后才自动启动后续依赖的作业。后续会逐步扩展依赖关系，实现 running / complete / probe 等多种依赖探测。
JobFlow 作业流引擎已经内置到博云智能算力平台中，用户可以通过简单的图形页面实现复杂的作业模板定义、依赖管理、作业提交、历史查询等高频操作。
03案例应用
通过一个简单的算术计算可以演示 JobFlow 的能力，该案例可以在B站博云账号下查看。如下图 job-d 依赖于 job-a 和 job-b 的运算结果。job-e 依赖于 job-c 的运算结果。job-f 依赖于 job-d 的运算结果。job-g 依赖于 job-e 的运算结果。job-h 依赖于 job-f 和 job-g 的运算结果。job-h 通过运算得到最终结果140 。
后续拓展
博云已于近期与 Volcano 社区就 JobFlow 成为 Volcano 子项目相关事宜进行探讨。合并完成后，所有使用 Volcano 进行作业编排调度的用户都可以直接使用该技术，同时保持极低的迁移成本。
除了更多的依赖关系，JobFlow 项目后续还会继续增加对 task 级别的任务划分以及下发。即直接描述 task 的依赖规则，jobflow 根据 task 的依赖规则对 task 进行划分，生成作业并下发。
