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

?在每个调度周期中,会按顺序执行OpenSession,配置的多个动作(action)和CloseSession 。在OpenSession中用户可以注册自定义的插件,例如gang、drf,这些插件为action提供了相应算法;多个action根据配置顺序执行,调用注册的插件进行调度;最后,CloseSession负责清理中间数据。

(1)action是第一级插件,定义了调度周期内需要的各个动作;默认提供enqueue、allocate、preempt和backfill四个action 。以allocate为例,它定义了调度中资源分配过程:根据plugin的JobOrderFn对作业进行排序,根据NodeOrderFn对节点进行排序,检测节点上的资源是否满足,满足作业的分配要求(JobReady)后提交分配决定。由于action也是基于插件机制,因此用户可以重新定义自己的分配动作,例如基于图的调度算法firmament 。

(2)plugin是第二级插件,定义了action需要的各个算法;以drf插件为例,为了根据dominantresource进行作业排序,drf插件实现了JobOrderFn函数。 JobOrderFn函数根据drf计算每个作业的share值,share值较低代表当前作业分配的资源较少,因此会为其优先分配资源;drf插件还实现了EventHandler回调函数,当作业被分配或抢占资源后,调度器会通知drf插件来更新share值。

?Cache不仅提供了集群的快照,同时还提供了调度器与kube-apiserver的交互接口,调度器与kube-apiserver之间的通信也都通过Cache来完成,例如Bind 。

同时,为了支持上面这些场景,Volcano的调度器还增加了多个Pod状态以提高调度的性能:

?Pending:当Pod被创建后就处于Pending状态,等待调度器对其进行调度;调度的主要目的也是为这些Pending的Pod寻找最优的资源

?Allocated:当Pod被分配空闲资源,但是还没有向kube-apiserver发送调度决策时,Pod处于Allocated状态。 Allocated状态仅存在于调度周期内部,用于记录Pod和资源分配情况。当作业满足启动条件时(e.g.满足minMember),会向kube-apiserver提交调度决策。如果本轮调度周期内无法提交调度决策,由状态会回滚为Pending状态。

?Pipelined:该状态与Allocated状态相似,区别在于处于该状态的Pod分配到的资源为正在被释放的资源(Releasing) 。该状态主要用于等待被抢占的资源释放。该状态是调度周期中的状态,不会更新到kube-apiserver以减少通信,节省kube-apiserver的qps 。

Volcano火山：容器与批量计算的碰撞。?Binding:当作业满足启动条件时,调度器会向kube-apiserver提交调度决策,在kube-apiserver返回最终状态之前,Pod一直处于Binding状态。该状态也保存在调度器的Cache之中,因此跨调度周期有效。

?Bound:当作业的调度决策在kube-apiserver确认后,该Pod即为Bound状态。

?Releasing:Pod等待被删除时即为Releasing状态。

?Running,Failed,Succeeded,Unknown:与Pod的现有含义一致。

状态之间根据不同的操作进行转换,见下图。