K8S的调度优先级与抢占机制

21 篇文章 3 订阅

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 里面,开始调度。

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

在这里插入图片描述

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值