volcano
# 1.简介
# 1.1.背景
volcano是一个基于kubernetes的批处理平台,提供高性能任务调度、高性能异构芯片管理及高性能任务运行管理相关的通用计算能力。
注意
volcano于2019年由华为云捐献给CNCF作为首个和唯一的孵化级容器批量计算项目,成为业界认可的事实标准
# 1.2.作用
volcano面向主流计算框架统一了容器基础设施,提供通用作业管理及资源利用调度,对于计算密集型应用极大简化了运维成本和部署难度。
补充
volcano由scheduler、controller-manager、admission和agent四部分组成,后面会介绍
# 1.3.组件
volcano由vcm、scheduler、admission和agent四部分组成,组件之间根据职责划分和有效的协作实现了完整的调度和作用批管理。
补充
vcm/scheduler/admission/agent组合应对不同工作负载,便于扩展插件增强能力
# 1.4.GPU
volcano提供了强大的vGPU调度能力,实现物理GPU在容器和作业间的有效共享,提高GPU资源利用和工作负载的资源调度成本。--- HAMI-core方案 基于vCUDA(劫持CUDA API)对GPU核心与显存的使用进行限制,实现软件层面的虚拟GPU切片,本质是基于底层库的显存限制 --- Dynamic MIG 基于NVIDIA的MIG(Multi-Instance GPU)技术,将GPU分割为多个具备硬件级性能保障的隔离实例,本质是直接切割GPU逻辑单元1
2
3
4
5
注意
volcano支持异构集群,允许同时存在HAMI-core模式节点和Dynamic MIG模式的节点,核心实现都在volcano-vgpu-device-plugin
# 2.扩展资源
# 2.1.Queue
Queue充当资源池的角色,用于容纳PodGroup及作为该组PodGroup获取集群资源的划分依据,允许根据业务需求或优先级将作业分组到不同队列。
注意
Queue是volcano调度的核心概念,用于优化多租户场景的资源隔离与划分
# 2.2.QueueTree
volcano scheduler默认创建root queue作为所有队列的根,后续创建的queue可以基于parent字段挂到队列树,用于后续检索抢占资源。
注意
queue pod资源不足会检查队列树抢占兄弟队列或祖先队列下pod资源,出于管理目的,限制叶子节点才能提交作业
# 2.3.Job
vcjob是volcano提供的一种高级作业资源类型,扩展了kubernetes原生的job资源,为高性能计算和批处理场景提供了更丰富的功能。
注意
vcjob支持一个作业定义不同task,提供更多高级策略及容错机制,适用于高性能计算和批处理场景
# 2.4.CronJob
cronvcjob用于根据预定义的调度计划周期创建和运行vcjob,类似于kubernetes原生的cronjob,提供了批量计算任务的定期执行能力。
注意
cronvcjob不会直接参与批计算及调度,仅负责周期创建vcjob及同步相关状态
# 2.5.PodGroup
PodGroup是volcano实现Gang Scheduling的核心资源对象,用于将一组相关的Pod视为一个整体进行调度,确保关联Pod调度的幂等性。
注意
PodGroup用于跟踪Batch Pod调度状态,限制最小成员数,确保批任务全部成功或不触发调度,避免部分调度造成的资源浪费
# 3.调度
# 3.1.kube-sched
AI Pod批调度要求遵循All Or Nothing理念,无法容忍一批作业的Pod部分调度情况,因此kube-scheduler无法适用AI作业需求。
补充
kube-scheduler没有内置完整的Gang Scheduling能力,不适用AI作业这类高性能计算场景
# 3.2.volcano-sched
volcano scheduler提供完整的Gang Scheduling能力,由一系列action和plugin组成,基于action+plugin组合提供完整的调度能力。--- 工作流程 1.提交的Job由scheduler观察及缓存 2.周期性开启会话,一个调度周期开始 3.未调度的Job发送到会话的待调度队列 4.基于待调度Job依次执行enqueue-allocate-preempt-reclaim-backfill等action,找到最合适的节点绑定Job 5.会话结束1
2
3
4
5
6
补充
action定义调度环节需要执行的动作,plugin根据不同场景提供action需要的算法实现
# 3.3.sched状态
volcano基于kubernetes原生Pod状态进行相关扩展,补充了session周期状态和cache暂存状态优化调度性能,采用更精细的策略执行调度。
注意
cluster/session/cache之间的状态可以相互转换,图中标记的转换流
# 4.控制器
# 4.1.vcm
volcano controller负责监听自定义资源(Job/PodGroup/Queue...),基于不同controller协调调度Pod及限制资源访问与分配。
注意
volcano controller核心控制器是job/podgroup/queue
# 4.2.registry
volcano加载的控制器需实现controller接口,启动时基于init()注册到global controllers列表,由main入口激活各controller。// Controller is the interface of all controllers. type Controller interface { Name() string Initialize(opt *ControllerOption) error // 初始化 Run(stopCh <-chan struct{}) // 运行 } func init() { framework.RegisterController(&gccontroller{}) } // RegisterController register controller to the controller manager. func RegisterController(ctrl Controller) error { if ctrl == nil { return fmt.Errorf("controller is nil") } // 禁止重复注册 if _, found := controllers[ctrl.Name()]; found { return fmt.Errorf("duplicated controller") } controllers[ctrl.Name()] = ctrl return nil }1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27补充
registerController注册的控制器后续会基于startControllers()统一激活
# 4.3.start
run()函数进行准备工作,加载注册的controller构造为runHook,基于直接运行和选举运行策略执行runHook()激活各controller。// Run the controller. func Run(opt *options.ServerOption) error { ... // controller runHook run := startControllers(config, opt) ... // 执行运行 if !opt.LeaderElection.LeaderElect { run(ctx) return fmt.Errorf("finished without leader elect") } ... // 选举执行 leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{ Lock: rl, LeaseDuration: 60s, RenewDeadline: 20s, RetryPeriod: 10s, Callbacks: leaderelection.LeaderCallbacks{ OnStartedLeading: run, ... }, }) return fmt.Errorf("lost lease") } func startControllers(config *rest.Config, opt *options.ServerOption) func(ctx context.Context) { ... return func(ctx context.Context) { framework.ForeachController(func(c framework.Controller) { // if controller is not enabled, skip it if !isControllerEnabled(c.Name(), opt.Controllers) { return } // 初始化 c.Initialize(controllerOpt) ... // 启动controller go c.Run(ctx.Done()) }) <-ctx.Done() } }1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
补充
controller有众多实现,比较核心的是queue/job/podgroup,后续会依次分析