Z.S.K.'s Records

Kube-batch学习(核心模块)

接上篇,主要介绍了kube-batch中两个重要的对象,queue及podgroup,这次主要讲讲kube-batch的核心的几个模块

默认配置

以下是kube-batch默认的配置,如下:

1
2
3
4
5
6
7
8
9
10
actions: "allocate, backfill"
tiers:
- plugins:
- name: priority
- name: gang
- plugins:
- name: drf
- name: predicates
- name: proportion
- name: nodeorder

可以看到分为actions及tiers,其中actions指定了kube-batch在调度时需要执行的操作,同时,这些操作会关联一些plugins(简单来说就是一些算法)来实现相关功能,比如说,actions是allocate,allocate意为分配资源,但是在分配资源时有时也会有一些要求,比如优先级高的先分配,或者把某个任务当成一个整体进行分配(gang)等等,同时,不同的actions可能关联同一个plugins,比如对于资源回收时,也可能存在先回收优先级低的pod的资源,这就是actions及plugins之间的关系

kube-batch支持多种的actions及plugins,这个则需要根据实际的情况按需选择

列表如下:

  • actions
    • allocate
    • backfill
    • preempt
    • reclaim
  • plugins
    • conformance
    • drf
    • gang
    • nodeorder
    • predicates
    • priority
    • proportion

要注意的是,配置文件中actions及plugins的指定顺序非常重要,kube-batch不会考虑action及plugins列表之间的顺序是不是合理,它只会按照指定的顺序依次执行,因此,要根据实际情况谨慎、实操地对配置进行优化,最后才能达到合理效果

tiers下的plugins是列表结构,对于actions来说,如果遇到了优先级更高的plugins,则不会再进行应用低优先级的plugins,比如上面的配置中,如果一个优先级高的跟一个优先级低的任务同时到来,则优先级高的获取到它需要的所有资源,而不会再考虑其它的plugins,如果两者优先级一样且都是以podgroup存在,则就会按drf plugins进行处理.

这张图很形象地说明kube-batch的工作原因

它通过 list-watch 监听 Pod, Queue, PodGroup 和 Node 等资源,在本地维护一份集群资源的全局缓存,依次通过如下的策略(reclaim, allocate, preemption,predict) 完成资源的调度

cache

Cache模块封装了对API Server的节点、容器等对象的数据同步逻辑。Kubernetes的数据保存在分布式存储etcd中,所有对数据的查询和操作都通过调用API Server的接口,而非直接操作etcd。在调度时,需要集群中的节点和容器的使用资源和状态等信息。Cache模块通过调用Kubernetes的SDK,通过watch机制监听集群中的节点、容器的状态变化,将信息同步到自己的数据结构中。

Cache模块还封装了对API server的接口的调用。比如Cache.Bind这个接口,会去调用API Server的Bind接口,将容器绑定到指定的节点上。在kube-batch中只有cache模块需要和API Server交互,其他模块只需要调用Cache模块的接口,一方面减少api-server的压力,另一方面加快kube-batch本身的调度性能

session

Session模块是将其他三个模块串联起来的一个模块。Kube-batch在每个调度周期开始时,都会新建一个Session对象,这个Session的初始化时,会做以下操作:

  • 调用Cache.Snapshot接口,将Cache中节点、任务和队列的信息拷贝一份副本,之后在这个调度周期中使用这份副本进行调度。因为Cache的数据会不断变化,为了保持同个调度周期中的数据一致性,在一开始就拷贝了一份副本。
  • 将配置中的各个Plugin初始化,然后调用plugin的OnSessionOpen接口。Plugin在OnSessionOpen中,会初始化自己需要的数据,并将一些回调函数注册到session中。Plugin可以向Session中注册的函数是:
    1. jobOrderFns: 决定哪个训练任务优先被处理(调度、回收、抢占)
    2. queueOrderFns:决定哪个训练队列优先被处理
    3. taskOrderFns:决定任务中哪个容器优先被处理
    4. predicateFns: 判断某个节点是否满足容器的基本调度要求。比如容器中指定的节点的标签
    5. nodeOrderFns: 当多个节点满足容器的调度要求时,优先选择哪个节点
    6. preemptableFns: 决定某个容器是否可以被抢占
    7. reclaimableFns :决定某个容器是否可以被回收
    8. overusedFns: 决定某个队列使用的资源是否超过限额,是的话不再调度对队列中的任务
    9. jobReadyFns:判断某个任务是否已经准备好,可以调用API Server的接口将任务的容器调度到节点
    10. jobPipelinedFns : 判断某个任务是否处于Pipelined状态
    11. jobValidFns: 判断某个任务是否有效

注意Plugin不需要注册上面所有的函数,而是可以根据自己的需要,注册某几个函数。比如Predict plugin就只注册了predicateFns这个函数到Session中。

初始化成功后,Kube-batch会依次调用不同的Action的Execute方法,并将Session对象作为参数传入。在Execute中,会调用Session的各种方法。这些方法,有些最终会调用到Cache的方法, 有些是调用Plugin注册的方法。

actions

因为业务中只使用到了默认的action,因此就简单说下allocate跟backfill这两个,其它的如reclaim跟preempt可参考这里

allocate

allocate用于将有明确资源需求的pod(task)分配到某个节点,在k8s对象中,pod或者container有没有指定request及limit,对应不同的Qos,Qos表示为服务质量,在这里不展开说明,感兴趣的可参考这里,对于明确指定了requests跟limit且相等的这类pod,对应的Qos为guaranteed,同等情况下会被优先保障资源。

如果不额外配置,allocate在kube-batch是默认的选项

那如果有pod没有指定资源怎么办呢?

backfill

这个时候就需要靠backfill(回填)这个action来处理了,这个模块主要实现当podgroup中有pod没有被绑定成功时,其它的绑定的pod的资源会释放,在podgroup中非常关键.

Plugins

gang

gang翻译成中文是帮派的意思,电影中的帮派大多都是共进退的,因为gang插件实现的就是帮派调度,gang-scheduler是podgroup中的核心,实现All or Nothing的效果

那么Kube-batch如何Gang-Scheduler,逻辑如下:

  • 增加一个PodGruop的CRD。调度以PodGroup为单位。同时对应还有一个PodGroupController进行PodGroup的管理
  • 整个调度过程采用延迟创建Pod的过程。只有当PodGroup中的所有Pod都有合适的Node绑定时,才开始创建
  • c. 定义了一种新的Action-BackFill.当PodGroup还有Pod没绑定时,之前绑定Pod的资源会释放

gang注册3个function,分别是:

  • preemptableFn 为避免gang的策略被preempt和reclaim干扰,定义了preemptableFn,排除那些还未准备就绪的job,避免其被抢占。(虽然实际上这些job未真正调度到node上去,但是确实从逻辑上把资源分配给它了)
  • jobOrderFn 为让已经就绪的job尽快被调度到节点,定义了jobOrderFn ,让已经就绪的job拥有更高的优先级
  • jobReadyFn 用来判断一个job是否已经就绪。jobReady会调用所有注册了的 plugin的Ready判定函数,只有都判定为ready ,才返回true

DRF

实现了Dominant Resouce Fairenss算法,这个算法能够有效对多种资源(CPU、Memory、GPU)进行调度

Drf目的是尽量避免集群内某一类资源使用比例偏高,而其他类型资源使用比例却很低的不良状态。在调度时,让具有最低资源占用比例的任务具有高优先级,主要关注onSessionOpen函数:

  • 统计集群中所有node可分配资源总量
  • 统计Job资源申请,计算资源占比(资源申请/资源总量)
  • 注册Job排序函数,根据资源占比进行排序,主要资源占比越低job优先级越高
  • 注册事件处理函数,包括分配函数以及驱逐函数,函数实现比较简单,就是当task发生变化时,增加(分配)/减少(驱逐)Job资源申请总量,并且更新资源占比。

 drf注册2个function,分别是:

  • jobOrderFn 是job的排序函数,会让share值越小的job排在最前面,即拥有最高的优先级,这个是实现drf的关键。
  • preemptableFn返回可抢占的job列表,job的筛选规则是:如果待选job的share值大于将被调度的job的share值,则选中该待选job

kub-batch的session跟cache机制是固定的,主要通过action跟plugins机制来实现多样化调度算法.

虽然目前业务上运行的很ok,但根据本人的实践情况来看,不太建议生产使用,原因如下:

本人因为历史原因,接入kube-batch是目前最好的选择,由于kube-batch项目基本已不再维护,其中的有些bug已经有人提issue,但并没有在kube-batch这个项目中fix,而是直接在volcano的fix列表中了,所以如果需要fix,还需要从volcano中cherry-pick过来,但是虽说volcano是基于kube-batch而来,但volcano的版本迭代非常快,真的很难判断cherry-pick过来之后会不会有其它问题,如果有问题再来看volcano,如没有特殊原因还不如直接从一开始就使用上volcano,多快好省.

参考文章:

转载请注明出处https://izsk.me

Z.S.K. wechat
Scan Me To Read on Phone
I know you won't do this,but what if you did?