k8s默认的调度器无法更好地实现对pod的All or Nothing调度能力, 在HPC或者分布式训练场景中,批处理能力对资源的使用率尤为重要.
All or Nothing
考虑以下场景:
有一个训练任务需要10个工作负载一起运行,每个工作负载负责其中一部分,假如有一个工作负载无法调度,则可遇见的结果是整个任务99%的概率会失败
则其它的工作负载在条件允许的情况下也不应该运行,运行起来只会白白浪费资源,这里要说明的是,作者目前所在的项目是负责一个分布式训练平台,还未实现增量训练功能,因此不进行调度则会更加合理,因为可以把这部分资源让给其它训练任务,因此需要引进批处理调度器,要么都进行调度,要么一个都不调度,这就是All or Nothing
目前对于基于kubernetes常用的开源批调度器有2个,一个是volcano,一个是kube-batch
CNCF大家庭中第一个批处理调度器是volcano,是由华为基于kube-batch开发而来,而Kube-batch这个项目目前也基于停止维护, 其作者已成为volcano项目的maintainer,偶尔会有fix,不过就作者目前所在的分布式训练项目而言, 经过作者的调研,引进volcano会有相当大的改造成本,短时间无法完成,反而kube-batch的接入比较快,改造较小。
For What?
从kube-batch的readme.md来看,kube-batch主要聚焦在任务的批调度
及对多租户
的资源共享,而批调度使用的则是PodGroup
将一组关联的pod当成一个group,从而在pod的概念之上又封装了一层,实现了对整体group的调度,要么都成功,要么都失败.
多租户则是使用的是queue,为每个租户都属于一个queue, 一个queue又与特定的资源绑定,这样可以实现同一个queue中使用的资源量,当然,kube-batch支持引入插件对queue间进行一引起操作,比如有优先级、资源抢占等功能
podgroup及queue不在这里展开,后续用单独的篇幅说明
Can’t
Kube-batch用于Kubernetes的批调度器,对于某些场景是不适合的,比如数据管理、多租户的隔离、运行时等能力。
很多大厂都在训练场景中引入了kube-batch,像百度、华为、vivo等,当然都基于此进行了二次开发,从公开的网站信息来看,除了华为的volcano最受欢迎之外,vivo对kube-batch的宣讲最多,很多东西也可借鉴
目前,作者所在的团队调度器一期项目主要是基于kube-batch,在调度器二期中将可能引入volcano,使功能更加完善
接下来的几篇文章都是围绕kube-batch这个工具的概念、使用以及在项目中引入kube-batch后对资源的使用率有什么影响.