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后对资源的使用率有什么影响.
