Volcano 1.0：分布式调度系统漫谈
在分析趋势之前，我们先看一下分布式调度系统的历史。早期分布式调度系统以批处理系统为主，例如九几年的LSF/SGE/PBS等，这些批处理系统大规划的使用在HPC领域，而且对作业级的调度进行大量的研究工作；后续由批处理系统延伸出多集群、多组织资源共享的需求，便成了网络计算。
网络计算与云计算最大的不同是：网络计算强调多组织的资源共享，而云计算强调云厂商的集中式支持。这也是云计算成为主流的主要原因：多组织之间共享需要完备的协议和足够的安全支持，而云服务仅需要对用户提供相应服务和安全，并不需要在多个云厂商之间进行共享。
随着开源社区的发展，再将应用接口逐步统一，e.g. Kubernetes。Hadoop出现后，不仅推动了分布式调度系统中对数据的处理，同时也推动了开源软件的生态。2012和2014是两个重要的节点，Hadoop将资源管理层与领域框架层分开，随后的领域框架也有机会构建自己的生态，e.g. Spark；同时，将资源管理层与领域框架分开也被广泛认可。
在容器及Kuberentes流行后，凭借其高资源利用率与隔离，环境标准化等优势，越来越多的人希望将这些批量计算应用统一到 Kubernetes 平台上。
未来的趋势
多种应用统一调度
随着各行各业的发展，涌现出越来越多的领域框架来支持业务的发展；这些框架都在相应的业务领域有着不可替代的作用，e.g. Spark, Tensorflow, Flink等。在业务复杂性能不断增加的情况下，单一的领域框架很难应对现在复杂的业务场景；因此现在普遍使用多种框架达成业务目标，如下图所示。
但随着各个领域框架集群的不断扩大，以及单个业务的波动性，各个子集群的资源浪费比较严重，因此越来越多的用户希望通过统一调度系统来解决资源共享的问题。在技术选型上，Kubernetes凭借其优秀的扩展性获得大部分用户青睐。
异构硬件
在批量计算任务向云原生环境迁移的过程中，对云原生环境的算力提出了新的要求。各个厂商为了应对这些新的需求，为各个场景提供了不同架构的硬件，例如 鲲鹏，昇腾，X86，GPU等。当多种应用运行在统一平台上时，需要云原生调度系统能够对异构硬件资源进行统一的管理与调度，使用各种应用达到最优的资源配比。目前，硬件的信息通过kubernetes的 device plugin 机制提供，但Kubernetes的 device plugin 仍有一些不足，例如 无法很好的支持硬件拓扑。
在调度方面 Volcano 已经支持主流的调度策略，并在最新的1.0版本中支持了 GPU 共享，大大增加了GPU的利用率，有效降低了GPU的使用成本。
跨集群/跨云
跨集群一直是分布调度系统解决大规模、灾备等问题的主要解决方案。同时，为了降低厂商绑定的风险，并最大限度兼顾不同云厂商的优势，多云环境下的负载高效分发逐渐成为趋势。
在多云的环境中，面向数据位置的优化，作业执行时间预估等问题都是需要调度系统解决的问题；在 Volcano 中，将通过多个项目实现跨集群、跨云的作业调度。
例如：JobForward (#880)
https://github.com/volcano-sh/volcano/issues/880
智能化
调度算法在分布调度系统中有大量的研究，从早期的批处理系统到近期的Borg，Volcano等；早期的批处理系统以特定场景的算法优化为主，对于复杂的场景需要大量的计算，虽然有大量针对HPC和网络的调度优化，但常用和落地的算法比较少。
随着人工智能的发展，越来越多的调度系统将会使用AI相应的能力对算法进行优化。在 Volcano 中，将通过AI的能力驱动 Volcano 中各个调度算法进行优化，并通过AI的能力提供新的调度算法。
总结
分布式调度系统是一个复杂的系统，需要多个组件共协作以提高整体的效率，例如 应用管理，调度，异构硬件管理，存储等，仅靠调度器无法完成这些工作。
Volcano 作为CNCF首个面向批量计算的分布式调度系统，包含了应用管理，作业调度，异构硬件等多个组件和功能，其调度器兼容kubernetes调度策略，同时支持在线、离线两种作业类型，控制器提供了统一的作业管理，支持多种作业的接入，包括 MPI, Tensorflow, MidSpore, Spark 等，设备插件提供了对异构硬件的支持。例如 1.0 版中支持了 GPU 共享。
因此，Volcano面向分布式调度系统的趋势提供了完整的方案，可以在多种场景下提高作业性能，资源使用率等。