k8s调度系统以及机器学习平台任务批调度简介

k8s调度系统以及机器学习平台任务批调度简介
本文主要介绍了机器学习平台在深度学习任务的批调度上的一些工作以及对k8s调度机制原理的介绍。
背景介绍
近几年来，AI和大数据异常火热，伴随着AI经常出现的一个词就是机器学习平台，作为一个机器学习平台，平台提供训练所需要的硬件资源，平台也支持使用tfjob分布式训练模型，由于平台部署在私有集群，所以集群内项目的资源是有限的，在项目初期，项目训练任务不多的时候，每个任务都能获取足够的资源进行训练。随着项目里的训练任务越来越多，逐渐暴露出了一些在任务调度上的问题:

1. 多个tfjob同时提交会发生资源竞争而产生任务死锁，多个任务都无法正常完成。
2. 单个超大资源的训练任务长期抢占剩余资源(剩余资源也不够此任务启动)，后续的小资源任务也无法获得资源。
3. 业务方需要手动错峰提交训练任务，加大业务方工作量。
4. 业务方无法判断夜里cpu利用率低是团队训练资源没充分利用还是资源竞争导致死锁，无法进行资源优化。
   出现问题的原因是当前k8s的默认调度器只支持对单个pod的调度，对tfjob这种对应多个pod并且需要同时启动的任务无法做到批调度，这些问题影响了平台资源利用率，也影响了业务方的模型训练效率，成为平台需要解决的痛点之一。

由于平台整个构建在k8s集群上，在介绍平台批调度实践之前，需要先了解k8s原生的调度逻辑。
kube-scheduler
kube-scheduler是 kubernetes 的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是我们选择使用 kubernetes 一个非常重要的理由。
调度流程
下面介绍下kubernete调度程序是如何工作的:

1. 默认调度器根据指定的参数启动（如果使用 kubeadm 搭建的集群，启动配置文件位于 /etc/kubernetes/manifests/kube-schdueler.yaml）
2. watch apiserver，将 spec.nodeName 为空的 Pod 放入调度器内部的调度队列中
3. 从调度队列中 Pop 出一个 Pod，开始一个标准的调度周期。
4. 从 Pod 属性中检索“硬性要求”（比如 CPU/内存请求值，nodeSelector/nodeAffinity），然后过滤阶段发生，在该阶段计算出满足要求的节点候选列表。
5. 从 Pod 属性中检索“软需求”，并应用一些默认的“软策略”（比如 Pod 倾向于在节点上更加聚拢或分散），最后，它为每个候选节点给出一个分数，并挑选出得分最高的最终获胜者。
6. 和 apiserver 通信（发送绑定调用），然后设置 Pod 的 spec.nodeName 属性表示将该 Pod 调度到的节点。
   从上面的逻辑可以看出k8s调度的粒度是针对pod, 没有对pod按组调度的概念，想要实现批调度就需要在原生的调度器上做一些扩展，这一点k8s社区也早已考虑到，并提供了一些调度上的扩展方法。
   kube-scheduler扩展
   默认情况下，kube-scheduler提供的默认调度器能够满足我们绝大多数的要求，可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。
   另外伴随着Kubernetes在公有云以及企业内部IT系统中广泛应用，越来越多的开发人员尝试使用Kubernetes运行和管理Web应用和微服务以外的工作负载。典型场景包括机器学习和深度学习训练任务，高性能计算作业，基因计算工作流，甚至是传统的大数据处理任务。此外，Kubernetes集群所管理的资源类型也愈加丰富，不仅有GPU，TPU和FPGA，RDMA高性能网络，还有针对领域任务的各种定制加速器，kube-scheduler的调度能力已经不能完美满足上述各种场景，这就需要能对调度做一些定制修改。
   早期方案
   最初对于Kube-scheduler进行扩展的方式主要有两种，一种是调度器扩展（Scheduler Extender）， 另外一种是多调度器（Multiple schedulers）。接下来我们对这两种方式分别进行介绍和对比。
   Scheduler Extender
   对于Kubernetes项目来说，它很乐意开发者使用并向它提bug或者PR(受欢迎)，但是不建议开发者为了实现业务需求直接修改Kubernetes核心代码，因为这样做会影响Kubernetes本身的代码质量以及稳定性。因此Kubernetes希望尽可能通过外围的方式来解决客户自定义的需求
   其实任何好的项目都应该这样思考：尽可能抽取核心代码，这部分代码不应该经常变动或者说只能由maintainer改动(提高代码质量，减小项目本身开发&运维成本)；将第三方客户需求尽可能提取到外围解决(满足客户自由)，例如：插件的形式(eg: CNI，CRI，CSI and scheduler framework etc)。
   社区最初提供的方案是通过Extender的形式来扩展scheduler。Extender是