kube-scheduler源码分析（3）中抢占调度机制是如何实现的？

kube-scheduler源码分析（3）-抢占调度分析 kube-scheduler简介 kube-scheduler组件是kubernetes中的核心组件之一，主要负责pod资源对象的调度工作，具体来说，kube-scheduler组件负责根据调度算法（包括预选算法和优选算法）将未调度的pod调度到合适的最优的node节点上。 kube-scheduler架构图 kube-scheduler的大致组成和处理流程如下图，kube-scheduler对pod、node等对象进行了list/watch，根据informer将未调度的pod放入待调度pod队列，并根据informer构建调度器cache（用于快速获取需要的node等对象），然后sched.scheduleOne方法为kube-scheduler组件调度pod的核心处理逻辑所在，从未调度pod队列中取出一个pod，经过预选与优选算法，最终选出一个最优node，上述步骤都成功则更新cache并异步执行bind操作，也就是更新pod的nodeName字段，失败则进入抢占逻辑，至此一个pod的调度工作完成。 kube-scheduler抢占调度概述 优先级和抢占机制，解决的是 Pod 调度失败时该怎么办的问题。 正常情况下，当一个 pod 调度失败后，就会被暂时 “搁置” 处于 pending 状态，直到 pod 被更新或者集群状态发生变化，调度器才会对这个 pod 进行重新调度。 但是有的时候，我们希望给pod分等级，即分优先级。当一个高优先级的 Pod 调度失败后，该 Pod 并不会被“搁置”，而是会“挤走”某个 Node 上的一些低优先级的 Pod，这样一来就可以保证高优先级 Pod 会优先调度成功。 关于pod优先级，具体请参考：https://kubernetes.io/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/ 抢占发生的原因，一定是一个高优先级的 pod 调度失败，我们称这个 pod 为“抢占者”，称被抢占的 pod 为“牺牲者”(victims)。 PDB概述 PDB全称PodDisruptionBudget，可以理解为是k8s中用来保证Deployment、StatefulSet等控制器在集群中存在的最小副本数量的一个对象。 具体请参考： https://kubernetes.io/zh/docs/concepts/workloads/pods/disruptions/ https://kubernetes.io/zh/docs/tasks/run-application/configure-pdb/ 抢占调度功能开启与关闭配置 kube-scheduler的抢占调度功能默认开启。 在 Kubernetes 1.15+版本，如果 NonPreemptingPriority被启用了（kube-scheduler组件启动参数--feature-gates=NonPreemptingPriority=true） ，PriorityClass 可以设置 preemptionPolicy: Never，则该 PriorityClass 的所有 Pod在调度失败后将不会执行抢占逻辑。 另外，在 Kubernetes 1.11+版本，kube-scheduler组件也可以配置文件参数设置将抢占调度功能关闭（注意：不能通过组件启动命令行参数设置）。 apiVersion: kubescheduler.config.k8s.io/v1alpha1 kind: KubeSchedulerConfiguration ... disablePreemption: true 配置文件通过kube-scheduler启动参数--config指定。 kube-scheduler启动参数参考：https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-scheduler/ kube-scheduler配置文件参考：https://kubernetes.io/zh/docs/reference/scheduling/config/ kube-scheduler组件的分析将分为三大块进行，分别是： （1）kube-scheduler初始化与启动分析； （2）kube-scheduler核心处理逻辑分析； （3）kube-scheduler抢占调度逻辑分析； 本篇进行抢占调度逻辑分析。