volcano架构设计与原理解读-4008云顶国际网站

技术火炬手 发表于 2021/01/28 15:48:47 2021/01/28
【摘要】 本文将就volcano产生的背景、架构设计与原理进行深度解读。

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

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

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

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

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

挑战 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

蓝色部分是 k8s本身的组件,绿色的部分是volcano新加的一些组件。

作业提交流程:

1、通过 admission 后,kubectl 将在 kube-apiserver中创建 job (volcano crd) 对像

2、jobcontroller 根据 job 的配置创建 相应的 pods e.g. replicas

3、podpodgroup创建 后,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, jobcontrollerpodgroupcontroller 以及 gc-controller

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

controller

左边为volcano job controller,不只调度使用的volcanojob的生命周期管理、作业管理都在这里面包含。我们提供了统一的作业管理,你只要使用volcano,也不需要创建各种各样的操作,就可以直接运行作业。

右边为crd job controller,通过下面的podgroup去做集成。

scheduler架构体系

scheduler支持动态配置和加载。左边为apiserver,右边为整个scheduler,apiserver里有jobpodpod groupscheduler分为三部分,第一层为cache,中间层为整个调度的过程,右边是以插件形式存在的调度算法。cache会将apiserver里创建的podpod group这些信息存储并加工为jobinfors。中间层的opensession会从cache里拉取podpod group,同时将右边的算法插件一起获取,从而运行它的调度工作。

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

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

pod的这些状态为调度器提供了更多优化的可能。例如,当进行pod驱逐时,驱逐在bindingbound状态的pod要比较驱逐running状态的pod的代价要小 (思考:还有其它状态的pod可以驱逐吗?);并且状态都是记录在volcano调度内部,减少了与kube-apiserver的通信。但目前volcano调度器仅使用了状态的部分功能,比如现在的preemption/reclaim仅会驱逐running状态下的pod;这主要是由于分布式系统中很难做到完全的状态同步,在驱逐bindingbound状态的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

volcanokubeflow 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%

mpi on volcano

规划

gpu共享特性

1)算力优化:

gpu硬件加速,tensorcore

gpu共享

昇腾改造

2)调度算法优化:

job/task模型,提供aijob统一批量调度

多任务排队,支持多租户/部门共享集群

job内多任务集群中最优化亲和性调度、gang scheduling

主流的ps-workerring allreduce等分布式训练模型

3)流程优化

容器镜像

cicd流程

日志监控

volcano可以支持更大规模的一个集群调度,我们现在是1万个节点百万容器,调度的性能每秒达到2000pod

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 star300 fork150 贡献者

  • 3 maintainer7 reviewer

  • 30 家企业、科研机构

目前使用volcano的部分企业

【4008云顶国际集团的版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。