43 | Kubernetes默认调度器的优先级与抢占机制

张磊



该思维导图由 AI 生成，仅供参考

你好，我是张磊。今天我和你分享的主题是：Kubernetes 默认调度器的优先级与抢占机制。
在上一篇文章中，我为你详细讲解了 Kubernetes 默认调度器的主要调度算法的工作原理。在本篇文章中，我再来为你讲解一下 Kubernetes 调度器里的另一个重要机制，即：优先级（Priority ）和抢占（Preemption）机制。
首先需要明确的是，优先级和抢占机制，解决的是 Pod 调度失败时该怎么办的问题。
正常情况下，当一个 Pod 调度失败后，它就会被暂时“搁置”起来，直到 Pod 被更新，或者集群状态发生变化，调度器才会对这个 Pod 进行重新调度。
但在有时候，我们希望的是这样一个场景。当一个高优先级的 Pod 调度失败后，该 Pod 并不会被“搁置”，而是会“挤走”某个 Node 上的一些低优先级的 Pod 。这样就可以保证这个高优先级 Pod 的调度成功。这个特性，其实也是一直以来就存在于 Borg 以及 Mesos 等项目里的一个基本功能。
而在 Kubernetes 里，优先级和抢占机制是在 1.10 版本后才逐步可用的。要使用这个机制，你首先需要在 Kubernetes 里提交一个 PriorityClass 的定义，如下所示：
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."

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Kubernetes调度器的优先级与抢占机制是本文的核心内容。文章详细介绍了在Kubernetes中定义和使用PriorityClass，以及抢占机制的设计原理，包括调度队列的实现、抢占者和牺牲者的概念，以及抢占算法的具体流程。特别强调了抢占过程中的特殊情况和处理方式，以及调度器在抢占者调度成功前的不确定性。此外，文章还探讨了调度器在执行Predicates算法时对潜在抢占者的特殊处理，以及为何需要执行两遍Predicates算法。总的来说，本文深入解析了Kubernetes调度器的优先级与抢占机制，为读者提供了全面的技术视角和理解。在本篇文章中，读者将深入了解Kubernetes中关于Pod的优先级和抢占机制的设计与实现。该特性已经在v1.11之后稳定，建议读者在Kubernetes集群中开启这两个特性，以实现更高的资源使用率。思考题提出了两个问题，分别涉及调度器执行MoveAllToActiveQueue操作的原因以及更新已调度成功的Pod时调度器将相关Pod移动到activeQ的原因。总的来说，本文为读者提供了深入了解Kubernetes调度器优先级与抢占机制的机会，同时也提出了思考题，引发读者对相关问题的思考。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Kubernetes》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(25)

最新
精选

黄巍
「调度器会开启一个 Goroutine，异步地删除牺牲者。」这里应该是同步的 :)
编辑回复: 已更新，感谢反馈~
2018-12-05
4
22
初学者
不太理解service与pod scheduling 流程有什么直接关系？
作者回复: 比如，同一个service 下的pod可以被打散。设置更复杂的service affinity规则。
2018-12-02

6
ch_ort
调度器的作用就是为Pod寻找一个合适的Node。调度过程：待调度Pod被提交到apiServer -> 更新到etcd -> 调度器Watch etcd感知到有需要调度的pod（Informer） -> 取出待调度Pod的信息 ->Predicates：挑选出可以运行该Pod的所有Node -> Priority：给所有Node打分 -> 将Pod绑定到得分最高的Node上 -> 将Pod信息更新回Etcd -> node的kubelet感知到etcd中有自己node需要拉起的pod -> 取出该Pod信息，做基本的二次检测（端口，资源等） -> 在node 上拉起该pod 。 Predicates阶段会有很多过滤规则：比如volume相关，node相关，pod相关 Priorities阶段会为Node打分，Pod调度到得分最高的Node上，打分规则比如：空余资源、实际物理剩余、镜像大小、Pod亲和性等 Kuberentes中可以为Pod设置优先级，高优先级的Pod可以： 1、在调度队列中先出队进行调度 2、调度失败时，触发抢占，调度器为其抢占低优先级Pod的资源。 Kuberentes默认调度器有两个调度队列： activeQ：凡事在该队列里的Pod，都是下一个调度周期需要调度的 unschedulableQ: 存放调度失败的Pod，当里面的Pod更新后就会重新回到activeQ，进行“重新调度” 默认调度器的抢占过程：确定要发生抢占 -> 调度器将所有节点信息复制一份，开始模拟抢占 -> 检查副本里的每一个节点，然后从该节点上逐个删除低优先级Pod，直到满足抢占者能运行 -> 找到一个能运行抢占者Pod的node -> 记录下这个Node名字和被删除Pod的列表 -> 模拟抢占结束 -> 开始真正抢占 -> 删除被抢占者的Pod，将抢占者调度到Node上
2020-12-20
3
92
马若飞
粥变多了，所有的僧可以重新排队领取了
2019-08-21

65
DJH
因为第一种情况下集群资源发生了变化，原先无法调度的pod可能有了可调度的节点或资源，不再需要通过抢占来实现。第二种情况是放pod调度成功后，跟这个pod有亲和性和反亲和性规则的pod需要重新过滤一次可用节点。
2018-11-30
1
12
虎虎❤️
Question 1: Add/update new node/pv/pvc/service will cause the change to predicates, which may make pending pods schedulable. Question 2: when a bound pod is added, creation of this pod may make pending pods with matching affinity terms schedulable. when a bound pod is updated, change of labels may make pending pods with matching affinity terms schedulable. when a bound pod is deleted, MatchInterPodAffinity need to be reconsidered for this node, as well as all nodes in its same failure domain.
2018-11-30

9
柯察金
为什么在为某一对 Pod 和 Node 执行 Predicates 算法的时候，如果待检查的 Node 是一个即将被抢占的节点，调度器就会对这个 Node ，将同样的 Predicates 算法运行两遍？感觉执行第一遍就可以了啊，难道执行第一遍成功了，在执行第二遍的时候还可能会失败吗？感觉第一遍条件比第二遍苛刻啊，如果第一遍 ok 第二遍也会通过的
2019-01-25
7
7
tianfeiyu
你好，我看了scheduler 代码，若抢占成功应该是更新 status.nominatedNodeName 不是 spec.nominatedNodeName 字段
2019-10-24
2
6
要没时间了
对于抢占调度，更多的是处理“使用了PriorityClass”且“需求资源不足”的Pod的调度失败case。在确定候选的nominatedNode的过程中，一个很重要的步骤就是模拟删除所有低优先级的pod，看剩余的资源是否符合高优先级Pod的需求。回忆下上一章提到的调度算法也能够清楚，除了资源不足的原因之外，其他调度失败的原因很难通过抢占来进行恢复。
2020-09-20

3
拉欧
增加调度效率吧，新增加资源的时候，一定有机会加速调度pod; 而一旦某个pod调度程度，马上检验和其相关的pod是否可调度
2019-11-23

2

收起评论