Volcano火山：容器与批量计算的碰撞( 五 ) 但随着Kuberentes的用户越

Pod的这些状态为调度器提供了更多优化的可能。例如,当进行Pod驱逐时,驱逐在Binding和Bound状态的Pod要比较驱逐Running状态的Pod的代价要小(思考:还有其它状态的Pod可以驱逐吗?);并且状态都是记录在Volcano调度内部,减少了与kube-apiserver的通信。但目前Volcano调度器仅使用了状态的部分功能,比如现在的preemption/reclaim仅会驱逐Running状态下的Pod;这主要是由于分布式系统中很难做到完全的状态同步,在驱逐Binding和Bound状态的Pod会有很多的状态竞争。

Volcano调度实现

Volcano调度器在支持上面这些主要场景时,分别使用了action和plugin两级插件。总体来讲,带有动作属性的功能,一般需要引入action插件;带有选择(包括排序)属性的功能,一般使用plugin插件。因此,这些常见场景中,fair-sharing、queue、co-scheduling都通过plugin机制来实现:都带有选择属性,比如“哪些作业应该被优先调度”;而preemption、reclaim、backfill、reserve则通过action机制来实现:都带有动作属性,比如“作业A抢占作业B” 。这里需要注意的是,action与plugin一定是一同工作的;fair-sharing这些plugin是借助allocate发展作用,而preemption在创建新的action后,同样需要plugin来选择哪些作业应该被抢占。这里通过job-basedfairness(DRF)和preempt两个功能的实现来介绍action和plugin两种插件机制的使用,其它功能类似:

?Job-basedFairness(DRF):目前的公平调度是基于DRF,并通过plugin插件来实现。在OpenSession中会先计算每个作业的dominantresource和每个作业share的初始值;然后注册JobOrderFn回调函数,JobOrderFn中接收两个作业对象,并根据对像的dominantresource的share值对作业进行排序;同时注册EventHandler,当Pod被分配或抢占资源时,drf根据相应的作业及资源信息动态更新share值。

其它插件的实现方案也基本相似,在OpenSession中注册相应的回调,例如JobOrderFn,TaskOrderFn,调度器会根据回调函数的结果决定如何分配资源,并通过EventHandler来更新插件内的调度数。

?Preemption:preempt是在allocate之后的一个action,它会为“高”优先级的Pending作业选取一个或多个“低”优先级的作业进行驱逐。由于抢占的动作与分配的动作不一致,因此新创建了preemptaction来处理相应的逻辑;同时,在选取高低优先级的作业时,preemptaction还是依赖相应的plugin插件来实现。其它动作插件的实现方式也类似,即根据需要创建整体的流程;将带有选择属性的问题转换为算法插件。

Volcano直播课:大神带你飞

6月4日晚20:00-21:00,Volcano/kube-batch创始人在线授课,不仅传授Volcano架构原理,还告诉你更多应用落地场景。

戳链接即可报名免费看直播:http://live.vhall.com/163509801

还有渔夫帽、双肩包等好礼相送!