Predicates预选算法过程分析
Scheduler工作流程
我们在使用K8S集群时,常常需要对Deployment Controller做创建、修改、删除操作,K8S对应的会创建、销毁和重新调度Pod在合适的节点上,这个调度过程是通过K8S的Scheduler调度器实现的。Schduler的工作流程如下图所示:
Informer组件一直在监听etcd中Pod信息的变化,准确来说,监听的是Pod信息中Spec.nodeName字段的变化,一旦检测到该字段为空,则认为集群中有Pod尚未调度到Node中,这时Informer开始将这个Pod的信息加入队列中,同时更新Scheduler Cache缓存。接下来Pod信息从队列中出队,进入Predicates(预选阶段),该阶段通过一系列的预选算法选出集群中适合Pod运行的节点,带着这些信息进入Priorities(优选阶段)。同理,该阶段通过一系列的优选算法为适合该Pod调度对每个Node进行打分,最后选出集群中最适合(也就是分数最高的)Pod运行的一个节点,最后将这个节点和Pod进行绑定(Bind),更新缓存,从而实现Pod的调度。
Predicates预选流程
predicates 算法主要是对集群中的 node 进行过滤,选出符合当前 pod 运行的一组 nodes。过滤 node 的预选算法有很多,比如:CheckNodeConditionPredicate(检查节点是否可被调度),PodFitsHost(检查pod.spec.nodeName字段是否已经指定),PodFitsHostPorts(检查pod需要的端口node能否提供)等,预选算法执行顺序如下:
var (
predicatesOrdering = []string{
CheckNodeConditionPred,
CheckNodeUnschedulablePred,
GeneralPred,
HostNamePred,
PodFitsHostPortsPred,
MatchNodeSelectorPred,
PodFitsResourcesPred,
NoDiskConflictPred,
PodToleratesNodeTaintsPred,
PodToleratesNodeNoExecuteTaintsPred,
CheckNodeLabelPresencePred,
CheckServiceAffinityPred,
MaxEBSVolumeCountPred,
MaxGCEPDVolumeCountPred,
MaxCSIVolumeCountPred,
MaxAzureDiskVolumeCountPred,
CheckVolumeBindingPred,
NoVolumeZoneConflictPred,
CheckNodeMemoryPressurePred,
CheckNodePIDPressurePred,
CheckNodeDiskPressurePred,
MatchInterPodAffinityPred}
)
这个顺序是可以被配置文件覆盖的,用户可以指定类似于这样的配置文件修改预选算法执行顺序:
{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
{
"name" : "PodFitsHostPorts", "order": 2},
{
"name" : "PodFitsResources", "order": 3},
{
"name" : "NoDiskConflict", "order": 5},
{
"name" : "PodToleratesNodeTaints", "order": 4},
{
"name" : "MatchNodeSelector", "order": 6},
{
"name" : "PodFitsHost", "order": 1}
],
"priorities" : [
{
"name" : "LeastRequestedPriority", "weight" : 1},
{
"name" : "BalancedResou