乐趣区

关于架构:一文带你解读Volcano架构设计与原理

摘要:Volcano 次要是基于 Kubernetes 做的一个批处理零碎,心愿下层的 HPC、中间层大数据的利用以及最上面一层 AI 可能在对立 Kubernetes 下面运行的更高效。

Volcano 产生的背景

上图是咱们做的一个剖析,咱们将其分为三层,最上面为资源管理层,两头为畛域的框架,包含 AI 的体系、HPC、Batch,WKflow 的治理以及像当初的一些微服务及流量治理等。再往上是行业以及一些行业的利用。

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

而当初,每天要收集大量的数据,它须要 spark 去做数据分析,甚至须要一些数据湖的产品去建设数据仓库,而后去做剖析,产生报表。同时它还会用 AI 的一些零碎,来简化业务流程等。

因而,当初的一些行业利用与 10 年前比,变得很简单,它可能会利用到上面这些畛域框架外面的一个或多个。其实对于行业利用,它的需要是在多个畛域框架作为一个交融,畛域框架的诉求是上面的资源管理层可能提供对立的资源管理。

Kubernetes 当初越来越多的承载了对立的资源管理的角色,它能够为 HPC 这些行业畛域框架提供服务,也能够作为大数据畛域的资源管理层。Volcano 次要是基于 Kubernetes 做的一个批处理零碎,心愿下层的 HPC、中间层大数据的利用以及最上面一层 AI 可能在对立 Kubernetes 下面运行的更高效。

Volcano 要解决什么样的问题?

挑战 1: 面向高性能负载的调度策略

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 会有很多的状态竞争。

在性能下面能带来哪些益处?

1)反对多种类型作业混合部署

2)反对多队列用于多租户资源共享,资源布局;并分时复用资源

3)反对多种高级调度策略,无效晋升整集群资源利用率

4)反对资源实时监控,用于高精度资源调度,例如 热点,网络带宽;容器引擎,网络性能优化, 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 后,很大概率呈现死锁;个别只能实现 2 个作业。

IOAware

3 个作业的执行工夫总和; 每个作业带 2ps + 4workers

默认调度器执行工夫稳定较大

执行工夫的进步量根据数据在作业中的比例而定

缩小 Pod Affinity/Anti-Affinity,进步调度器的整体性能

大数据场景

Spark-sql-perf (TP-DCS, master)

104 queries concurrently

(8cpu, 64G, 1600SSD) * 4nodes

Kubernetes 1.13

Driver: 1cpu,4G; Executor: (1cpu,4G)*5

如果没有固定的 driver 节点,最多同时运行 26 条查问语句

因为 Volcano 提供了作业级的资源预留,总体性能进步了~30%

HPC 场景

MPI on Volcano

布局

GPU 共享个性

1)算力优化:

GPU 硬件加速,TensorCore

GPU 共享

昇腾革新

2)调度算法优化:

Job/Task 模型,提供 AI 类 Job 对立批量调度

多任务排队,反对多租户 / 部门共享集群

单 Job 内多任务集群中最优化亲和性调度、Gang Scheduling 等

支流的 PS-Worker、Ring AllReduce 等分布式训练模型

3)流程优化

容器镜像

CICD 流程

日志监控

Volcano 能够反对更大规模的一个集群调度,咱们当初是 1 万个节点百万容器,调度的性能每秒达到 2000 个 Pod。

1) 编排:

Etcd 分库分表,e.g. Event 放到独自库,wal/snapshot 独自挂盘

通过一致性哈希扩散解决,实现 controller-manager 多活

Kube-apiserver 基于工作负载的弹性扩容

2) 调度:

通过 EquivalenceCache,算法剪枝 等技术晋升单调度器的吞吐性能

通过共享资源视图实现调度器多活,晋升调度速率

3) 网络:

通过 trunkport 晋升单节点容器密度及单集群 ENI 容量

通过 Warm Pool 预申请网口,晋升网口发放速度

基于 eBPF/XDP 反对大规模、高度变动的云原生利用网络,e.g. Service, network policy

4) 引擎:

containerd 并发 启动优化

反对 shimv2,晋升单节点容器密度

镜像下载减速 Lazy loading

Cromwell 社区集成

Cromwell 是一个流程调度软件,它能够定义不同的作业,这个软件在基因测序以及基因计算畛域里利用是比拟宽泛的。

Cromwell 社区原生反对 Volcano

企业版曾经上线 华为云 GCS

通过 cromwell 反对作业依赖

Volcano 提供面向作业、数据依赖的调度

Volcano CLI

KubeSim

简介:

集群进行性能测试及调度的形容工具

不受资源限度,模仿大规模 K8S 集群

残缺的 K8S API 调用,不会真正创立 pod

曾经反对产品侧大规模专项及调度专项的模仿工作

总体构造:

Worker cluster:承载 kubemark 虚构节点,hollow pod

Master cluster:治理 kubemark 虚构节点,hollow node

Hollow pod = hollow kubelet + hollow proxy

社区活跃度:

• 1.4k star,300+ fork,150+ 贡献者

• 3 Maintainer,7 Reviewer

• 30 家企业、科研机构

目前应用 Volcano 的局部企业

点击关注,第一工夫理解华为云陈腐技术~

退出移动版