Volcano 架构设计与原理介绍

关注

发布于: 2021 年 01 月 15 日

Volcano 是一个基于 Kubernetes 的云原生批量计算平台，也是 CNCF 的首个批量计算项目。

Volcano 主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。它提供高性能计算任务调度，异构设备管理，任务运行时管理等能力，目前在很多领域都已落地应用。本篇文章主要分享 Volcano 架构设计与原理。

Volcano 产生的背景

上图是我们做的一个分析，我们将其分为三层，最下面为资源管理层，中间为领域的框架，包括 AI 的体系、HPC、Batch， WKflow 的管理以及像现在的一些微服务及流量治理等。再往上是行业以及一些行业的应用。

随着一些行业的应用变得复杂，它对所需求的解决方案的要求也越来越高。举个例子在 10 多年以前，在金融行业提供解决方案时，它的架构是非常简单的，可能需要一个数据库，一个 ERP 的中间件，就可以解决银行大部分的业务。

而现在，每天要收集大量的数据，需要 spark 去做数据分析，甚至需要一些数据湖的产品去建立数据仓库，然后去做分析，产生报表。同时它还会用 AI 的一些系统，来简化业务流程等。

因此，现在的一些行业应用与 10 年前比，变得很复杂，它可能会应用到下面这些领域框架里面的一个或多个。其实对于行业应用，它的需求是在多个领域框架作为一个融合，领域框架的诉求是下面的资源管理层能够提供统一的资源管理。

Kubernetes 现在越来越多的承载了统一的资源管理的角色，它可以为 HPC 这些行业领域框架提供服务，也可以作为大数据领域的资源管理层。Volcano 主要是基于 Kubernetes 做的一个批处理系统，希望上层的 HPC、中间层大数据的应用以及最下面一层 AI 能够在统一 Kubernetes 上面运行的更高效。

Volcano 要解决什么样的问题？

e.g. fair-share, gang-scheduling

挑战 2: 支持多种作业生命周期管理

e.g. multiple pod template, error handling

挑战 3: 支持多种异构硬件

e.g. GPU, FPGA

挑战 4: 面向高性能负载的性能优化

e.g. scalability, throughput, network, runtime

挑战 5：支持资源管理及分时共享

e.g. Queue, Reclaim

Volcano 架构体系

图中蓝色部分是 K8s 本身的组件，绿色的部分是 Volcano 新加的一些组件。

作业提交流程：

1）通过 Admission 后，kubectl 将在 kube-apiserver 中创建 Job (Volcano CRD) 对像

2）JobController 根据 Job 的配置创建相应的 Pods e.g. replicas

3）Pod 及 PodGroup 创建后，vc-scheduler 会到 kube-apiserver 获取 Pod/PodGroup 以及 node 信息

4）获取信息后，vc-scheduler 将根据其配置的调度策略为每一个 Pod 选取合适节点

5）在为 Pod 分配节点后，kubelet 将从 kube-apiserver 中取得 Pod 的配置，启动相应的容器

需要强调的几点：

vc-scheduler 中的调度策略都以插件的形式存在, e.g. DRF, Priority, Gang

vc-controllers 包含了 QueueController, JobController，PodGroupController 以及 gc-controller

vc-scheduler 不仅可以调度批量计算的作业，也可以调度微服务作业；并且可以通过 multi-scheduler 功能与 kube-scheduler 共存

部分组件介绍

Controller

左边为 Volcano Job Controller，不只调度使用的 Volcano，Job 的生命周期管理、作业管理都在这里面包含。我们提供了统一的作业管理，你只要使用 Volcano，也不需要创建各种各样的操作，就可以直接运行作业。右边为 CRD Job Controller，通过下面的 PodGroup 去做集成。

scheduler 架构体系

Scheduler 支持动态配置和加载。左边为 apiserver,右边为整个 Scheduler。apiserver 里有 Job、Pod、Pod Group；Scheduler 分为三部分，第一层为 Cache,中间层为整个调度的过程，右边是以插件形式存在的调度算法。

Cache 会将 apiserver 里创建的 Pod、Pod Group 这些信息存储并加工为 Jobinfors。中间层的 OpenSession 会从 Cache 里拉取 Pod、Pod Group，同时将右边的算法插件一起获取，从而运行它的调度工作。

状态之间根据不同的操作进行转换，见下图：

另外，我们在 Pod 和 Pod 的状态方面增加了很多状态，图中蓝色部分为 K8s 自带的状态；绿色部分是 session 级别的状态。一个调度周期，我们会创建一个 session，它只在调度周期内发挥作用，一旦过了调度周期，这几个状态它是失效的；黄色部分的状态是放在 Cache 内的。我们加这些状态的目的是减少调度和 API 之间的一个交互，从而来优化调度性能。

Pod 的这些状态为调度器提供了更多优化的可能。例如，当进行 Pod 驱逐时，驱逐在 Binding 和 Bound 状态的 Pod 要比较驱逐 Running 状态的 Pod 的代价要小 (思考：还有其它状态的 Pod 可以驱逐吗？)；并且状态都是记录在 Volcano 调度内部，减少了与 kube-apiserver 的通信。

但目前 Volcano 调度器仅使用了状态的部分功能，比如现在的 preemption/reclaim 仅会驱逐 Running 状态下的 Pod；这主要是由于分布式系统中很难做到完全的状态同步，在驱逐 Binding 和 Bound 状态的 Pod 会有很多的状态竞争。

在功能上面能带来哪些好处？

支持多种类型作业混合部署
支持多队列用于多租户资源共享，资源规划；
并分时复用资源
支持多种高级调度策略，有效提升整集群资源利用率
支持资源实时监控，用于高精度资源调度，例如热点，网络带宽；容器引擎，网络性能优化, e.g. 免加载

分布式训练场景：

Gang-scheduler

Case 1: 1 job with 2ps + 4workers
Case 2: 2 jobs with 2ps + 4workers
Case 3: 5 jobs with 2ps + 4workers

在 Volcano 和 kubeflow+kube-scheduler 中做对比，Case 1 在资源充足的时候效果是差不多的；Case 2 是在没有足够的资源的情况下同时运行两个作业，如果没有 gang-scheduling，其中的一个作业会出现忙等；Case 3 当作业数涨到 5 后，很大概率出现死锁。

IOAware