Big Picture

在调度过程中，会有各种预选和优选算法，在经过了那么多道门槛之后，一个POD才能完成调度，提供服务，在调度过程中，假设有一个很重要的系统服务调度失败了，导致了故障，为了避免这种情况，我们可以对该应用设置一个相对较高的优先级，在调度失败后，将一些优先级相对较低的不是那么重要的应用”挤走“，这就是K8S调度的优先级和抢占的作用。

优先级

K8S有一个专门的API对象，就是优先级，比如:

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."

Kubernetes规定优先级是一个32bit的整数,最大值不超过1000000000(10 亿,1 billion),并且值越大代表优先级越高.而超出10亿的值,其实是被Kubernetes保留下来分配给系统 Pod 使用的.这样做的目的,就是保证系统Pod不会被用户抢占掉。

然后在对应的pod内指定优先级:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

抢占

之前提到，K8S在发生调度失败后，会基于优先级进行抢占，抢占并不是简单的将Node上的低优先级的pod”挤走“，抢占的设计还是相对比较有意思的。

K8S内部在调度过程中，会维护2个队列，分别是activeQ和unschedulableQ。

activeQ

当K8S里新创建一个Pod的时候,调度器会将这个Pod入队到activeQ里面，然后调度器从这个队列里取出一个pod进行调度。

unschedulableQ

专门用来存放调度失败的pod,当一个unschedulableQ里的Pod被更新之后,调度器会自动把这个Pod移动到activeQ里。

抢占的基本流程:

先画个图:

1. 正常调度的pod会先放入activeQ, activeQ会经过正常的调度策略进行调度。
2. 调度失败后，将这个pod放入unreachableQ里，随后出发寻找牺牲者流程。
3. 在寻找牺牲者之前，先对失败原因检查下，看下是不是因为一些无法恢复的原因导致失败的，比如node-selector失败之类的。
4. 确认可以触发抢占后，scheduler 会拉取所有node的缓存信息，进行一次模拟抢占流程，基于影响集群稳定性最小原则，选出了哪些node上的哪些pod，可以成为”牺牲者”。
5. 对于选出的牺牲者pod，schedueler 会先清楚他们pod里的nominatedNodeName字段。
6. 然后更新抢占者pod，将nominatedNodeName改成第4步选出的node名字。
7. 由于抢占者pod已发生了更新，所以给他“重新做人”的机会，重新放入activeQ里。
8. 同时，开启一个新的协程，清理牺牲者node上对应的牺牲者pod。

抢占的异常流程

抢占者和牺牲者其实是相对的，或者说，优先级是相对的，抢占者在第一次流程后，一般会创建在之前模拟出来的那个牺牲者node上，但是，假设同样队列里有另外一个pod也正好要调度在那个node上，K8S会对这种情况做一些特殊处理，即对该node进行2次预选操作。

1. 第一次预选，假设抢占者已经在对应node上了，以这个前提进行一次预选算法。
2. 第二次预选，假设抢占者不在对应node上，以这个前提进行一次预选算法。

只有这两次预选都通过了，调度器才认为这个node和pod可以绑定，再进入后续的优选算法。第二预选比较奇怪，为什么需要假设抢占者不在node上呢，这是因为删除牺牲者操作，实际是调用了标准的DELETE API进行操作的，这是一个"优雅关闭"的操作,所以存在默认30S的退出时间，而30S内，可能会有很多变故，比如再重新调度的时候，Node服务器挂了或者有更加高优先级的pod需要抢占这个node，这些都导致了重新调度的失败，所以说，抢占者不一定会调度到对应的node上。

另外还有一种情况，假设整个K8S集群有了一个比较大的变化，比如新扩容了node节点等，scheduler会执行MoveAllToActiveQueue的操作,把所调度失败的Pod从unscheduelableQ移动到activeQ里面。

另外由于亲和性的存在，当一个已经调度成功的Pod被更新时,调度器则会将unschedulableQ里所有跟这个Pod有 Affinity/Anti-affinity关系的Pod,移动到 activeQ 里面，开始调度。

个人公众号, 分享一些日常开发，运维工作中的日常以及一些学习感悟，欢迎大家互相学习，交流