深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
22715 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 打通“容器技术”的任督二脉
免费
01 | 预习篇 · 小鲸鱼大事记(一):初出茅庐
02 | 预习篇 · 小鲸鱼大事记(二):崭露头角
03 | 预习篇 · 小鲸鱼大事记(三):群雄并起
04 | 预习篇 · 小鲸鱼大事记(四):尘埃落定
容器技术概念入门篇 (5讲)
05 | 白话容器基础(一):从进程说开去
06 | 白话容器基础(二):隔离与限制
07 | 白话容器基础(三):深入理解容器镜像
08 | 白话容器基础(四):重新认识Docker容器
09 | 从容器到容器云:谈谈Kubernetes的本质
Kubernetes集群搭建与实践 (3讲)
10 | Kubernetes一键部署利器:kubeadm
11 | 从0到1:搭建一个完整的Kubernetes集群
12 | 牛刀小试:我的第一个容器化应用
容器编排与Kubernetes作业管理 (15讲)
13 | 为什么我们需要Pod?
14 | 深入解析Pod对象(一):基本概念
15 | 深入解析Pod对象(二):使用进阶
16 | 编排其实很简单:谈谈“控制器”模型
17 | 经典PaaS的记忆:作业副本与水平扩展
18 | 深入理解StatefulSet(一):拓扑状态
19 | 深入理解StatefulSet(二):存储状态
20 | 深入理解StatefulSet(三):有状态应用实践
21 | 容器化守护进程的意义:DaemonSet
22 | 撬动离线业务:Job与CronJob
23 | 声明式API与Kubernetes编程范式
24 | 深入解析声明式API(一):API对象的奥秘
25 | 深入解析声明式API(二):编写自定义控制器
26 | 基于角色的权限控制:RBAC
27 | 聪明的微创新:Operator工作原理解读
Kubernetes容器持久化存储 (4讲)
28 | PV、PVC、StorageClass,这些到底在说啥?
29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起
30 | 编写自己的存储插件:FlexVolume与CSI
31 | 容器存储实践:CSI插件编写指南
Kubernetes容器网络 (8讲)
32 | 浅谈容器网络
33 | 深入解析容器跨主机网络
34 | Kubernetes网络模型与CNI网络插件
35 | 解读Kubernetes三层网络方案
36 | 为什么说Kubernetes只有soft multi-tenancy?
37 | 找到容器不容易:Service、DNS与服务发现
38 | 从外界连通Service与Service调试“三板斧”
39 | 谈谈Service与Ingress
Kubernetes作业调度与资源管理 (5讲)
40 | Kubernetes的资源模型与资源管理
41 | 十字路口上的Kubernetes默认调度器
42 | Kubernetes默认调度器调度策略解析
43 | Kubernetes默认调度器的优先级与抢占机制
44 | Kubernetes GPU管理与Device Plugin机制
Kubernetes容器运行时 (3讲)
45 | 幕后英雄:SIG-Node与CRI
46 | 解读 CRI 与 容器运行时
47 | 绝不仅仅是安全:Kata Containers 与 gVisor
Kubernetes容器监控与日志 (3讲)
48 | Prometheus、Metrics Server与Kubernetes监控体系
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
50 | 让日志无处可逃:容器日志收集与管理
再谈开源与社区 (1讲)
51 | 谈谈Kubernetes开源社区和未来走向
答疑文章 (1讲)
52 | 答疑:在问题中解决问题,在思考中产生思考
特别放送 (1讲)
特别放送 | 2019 年,容器技术生态会发生些什么?
结束语 (1讲)
结束语 | Kubernetes:赢开发者赢天下
特别放送 | 云原生应用管理系列 (1讲)
基于 Kubernetes 的云原生应用管理,到底应该怎么做?
深入剖析Kubernetes
登录|注册

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

张磊 2018-11-30
你好,我是张磊。今天我和你分享的主题是: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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 黄巍
    「调度器会开启一个 Goroutine,异步地删除牺牲者。」这里应该是同步的 :)

    编辑回复: 已更新,感谢反馈~

    2018-12-05
    6
  • pain
    为什么在为某一对 Pod 和 Node 执行 Predicates 算法的时候,如果待检查的 Node 是一个即将被抢占的节点,调度器就会对这个 Node ,将同样的 Predicates 算法运行两遍?

    感觉执行第一遍就可以了啊,难道执行第一遍成功了,在执行第二遍的时候还可能会失败吗?感觉第一遍条件比第二遍苛刻啊,如果第一遍 ok 第二遍也会通过的
    2019-01-25
    4
    4
  • DJH
    因为第一种情况下集群资源发生了变化,原先无法调度的pod可能有了可调度的节点或资源,不再需要通过抢占来实现。

    第二种情况是放pod调度成功后,跟这个pod有亲和性和反亲和性规则的pod需要重新过滤一次可用节点。
    2018-11-30
    1
    3
  • 剃刀吗啡
    粥变多了,所有的僧可以重新排队领取了
    2019-08-21
    2
  • tianfeiyu
    你好,我看了scheduler 代码,若抢占成功应该是更新 status.nominatedNodeName 不是 spec.nominatedNodeName 字段
    2019-10-24
    1
  • 虎虎❤️
    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
    1
  • 拉欧
    增加调度效率吧,新增加资源的时候,一定有机会加速调度pod; 而一旦某个pod调度程度,马上检验和其相关的pod是否可调度
    2019-11-23
  • 进击的菜鸟运维
    第一个问题:添加或者更新Node,整个集群的信息就可能发生变化,可能存在满足unscheduledQ中的Pod调度,所以要让它们试一下,不然永远就在黑屋子了。

    第二个问题:Pod更新,其对应的affnity都可能更新,所以要重新调度一次
    2019-11-11
  • tianfeiyu
    想问一下,没有开启优先级的 pod 没有 status.NominatedNodeName 字段,抢占过程这些 pod 也会被抢占吗?
    2019-10-23
  • Dale
    1、集群有更新,需要将失败的pod重新调度,放到ActiveQ中可以重新触发调度策略
    2、在predicate阶段,会对pod的node selector进行判断,寻找合适的node节点,需要通过将pod放到ActiveQ中重新触发predicate调度策略
    2018-12-13
  • zmoon
    被抢占的直接删除了么
    2018-12-06
  • 初学者
    不太理解service与pod scheduling 流程有什么直接关系?

    作者回复: 比如,同一个service 下的pod可以被打散。设置更复杂的service affinity规则。

    2018-12-02
  • 小小笑儿
    第一个问题:添加更新node,pv可能让pod变成可调度的状态,就不用走抢占的流程了,service的不太明白。
    第二个问题:对anti的同上
    2018-11-30
收起评论
13
返回
顶部