Kubernetes的调度机制
原文出处:https://segmentfault.com/a/1190000012709117
k8s的调度机制
scheduler组件
k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如:1.设置cpu、内存的使用要求;2.增加node的label,并通过pod.Spec.NodeSelector进行强匹配;3.直接设置pod的nodeName,跳过调度直接下发。
k8s 1.2加入了一个实验性的功能:affinity。意为亲和性。这个特性的设计初衷是为了替代nodeSelector,并扩展更强大的调度策略。
调度器的工作机制是这样的:
一、预备工作
1、缓存所有的node节点,记录他们的规格:cpu、内存、磁盘空间、gpu显卡数等;
2、缓存所有运行中的pod,按照pod所在的node进行区分,统计每个node上的pod request了多少资源。request是pod的QoS配置,可以参考之前的文章。
3、list & watch pod资源,当检查到有新的Pending状态的pod出现,就将它加入到调度队列中。
4、调度器的worker组件从队列中取出pod进行调度。
二、调度过程
1、先将当前所有的node放入队列;
2、执行predicates算法,对队列中的node进行筛选。这里算法检查了一些pod运行的必要条件,包括port不冲突、cpu和内存资源QoS(如果有的话)必须满足、挂载volume(如果有的话)类型必须匹配、nodeSelector规则必须匹配、硬性的affinity规则(下文会提到)必须匹配、node的状态(condition)必须正常,taint_toleration硬规则(下文会提到)等等。
2、执行priorities算法,对队列中剩余的node进行评分,这里有许多评分项,各个项目有各自的权重:整体cpu,内存资源的平衡性、node上是否有存在要求的镜像、同rs的pod是否有调度、node affinity的软规则、taint_toleration软规则(下文会提到)等等。
3、最终评分最高的node会被选出。即代码中suggestedHost, err := sched.schedule(pod)
一句(plugin/pkg/scheduler/scheduler.go
)的返回值。
4、调度器执行assume
方法,该方法在pod调度到node之前,就以“该pod运行在目标node上” 为场景更新调度器缓存中的node 信息,也即预备工作中的1、2两点。这么做是为了让pod在真正调度到node上时,调度器也可以同时做后续其他pod的调度工作。
5、调度器执行bind
方法,该方法创建一个Binding资源,apiserver检查到创建该资源时,会主动更新pod的nodeName
字段。完成调度。
nodeSelector
举例:
apiVersion: v1kind: Podmetadata: name: nginx labels: env: testspec: containers:- name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd
上面这个pod会且仅会被调度到带有disktype: ssd
这个label的node上。这是一种强规则,没有妥协,必须遵守。
affinity 和 anti-affinity
有亲和性规则,那么反亲和性规则肯定也要有。
亲和性规则实现了更丰富的规则表达方式。并且包含了nodeSelector的硬规则和另一种软规则。
软规则是一种优先规则,如果没有符合这个优先规则的节点,它仍然会被进行调度。
node亲和性
node亲和性和nodeSelector类似,通过label进行可调度node的过滤,现在有两种node亲和性:requiredDuringSchedulingIgnoredDuringExecution
和 preferredDuringSchedulingIgnoredDuringExecution
:
requiredDuringSchedulingIgnoredDuringExecution
强规则。和nodeSelector完全相同,以label进行强制的约束。需要指出的是:目前,如果一个node在运行时label发生了变化,变化后和其上运行的pod的requiredDuringSchedulingIgnoredDuringExecution
不再匹配,这个node上的pod也不会被驱逐,这个功能会在以后被改进,届时会增加一种类型RequiredDuringSchedulingRequiredDuringExecution
。
preferredDuringSchedulingIgnoredDuringExecution
软规则。举例来说:我们要将某个容器尽可能地调度到可用域X中,但如果不存在这个可用域或者可用域无法再运行pod,调度器也允许这个pod被调度到其他可用域。
以下是一个包含了强规则和软规则的案例:
apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/e2e-az-name operator: In values:- e2e-az1- e2e-az2 preferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference: matchExpressions:- key: another-node-label-key operator: In values:- another-node-label-value containers:- name: with-node-affinity image: gcr.io/google_containers/pause:2.0
该案例表明,这个pod只允许被调度到带有kubernetes.io/e2e-az-name=e2e-az1或e2e-az2
的label的node上,也即只允许被调度到e2e-az1或者e2e-az2两个可用域中;另外,pod要尽量调度到包含another-node-label-key
的值为another-node-label-value
的node上。
matchExpressions
结构记录各种表达式,一个表达式包含key
,operator
,values
,分别表示关键字、关键字匹配关系、关键字匹配值。匹配关系包括:In
,NotIn
,Exists
,DoesNotExist
,Gt
,Lt
。NotIn
和DoesNotExist
是node anti-affinity的一种表现。
如果一个pod的描述信息中同时包含了nodeSelector
和nodeAffinity
,那么调度时两个规则都要满足。
如果一个nodeAffinity
中包含了多条nodeSelectorTerms
, 调度器只需要满足其中一条; 如果一个 nodeSelectorTerms
中记录了多条matchExpressions
,那么调度器要满足所有的matchExpressions
inter-pod affinity 和 anti-affinity
这两个特性都包含在1.4版本中,上面的亲和性是node亲和性,这个就是pod亲和性,简而言之,要把pod调度到某个node上,这个node上已有的pod能满足、或尽量满足某些条件。这个特性用pod.spec.affinity.podAffinity
和pod.spec.affinity.podAntiAffinity
来表示。
pod亲和性的规则可以这么表示:
这个pod应该(或者不应该)运行在节点X上,X上必须已经运行了一个或多个满足规则Y的pod。规则Y的表达方式类似于一个labelSelector并关联了一个namespace列表:namespaces
(若没有则表示“allnamespaces”),X可能是node或一个az,我们通过字段topologyKey
来规划X,即所有的X都要满足topologyKey
相同,一般topologyKey
是一个label的key。
为什么要有namespace列表?因为和node不同,pod是有分namespace的,因此pod的label也是有分namespace的。在这种情况下,规则Y必须要指明自己这个规则要适用于哪些namespace。比如node上运行的是hy
这个namespace下的pod,即便pod的label和规则Y的nodeSelector都相同,我们也视为不符合规则。
和node亲和性一样,pod亲和性也包含两个(硬规则和软规则):
requiredDuringSchedulingIgnoredDuringExecution
: 硬规则。preferredDuringSchedulingIgnoredDuringExecution
:
举个例子:
apiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution:- labelSelector: matchExpressions:- key: security operator: In values:- S1 topologyKey: failure-domain.beta.kubernetes.io/zone podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm: labelSelector: matchExpressions:- key: security operator: In values:- S2 topologyKey: kubernetes.io/hostname containers:- name: with-pod-affinity image: gcr.io/google_containers/pause:2.0
上面的pod模板使用了podAffinity的硬规则和podAntiAffinity的软规则。
podAffinity规则中
topologyKey
是zone,也就是可用域,说明这条规则可以规划处调度到的域,首先,node上必须至少有一个running状态的pod包含key为security
,value为S1
的label。只要满足这个条件,那么这个node和其同一个域(拥有相同的failure-domain.beta.kubernetes.io/zone
为key,且值相同的label)的node均会被调度。podAntiAffinity规则中
topologyKey
是hostname,表明该规则约定了某种node尽量不会被调度到,这种node上已经运行了包含key为security
,value为S2
的label的pod。假如现在有node a,b,c,其中a和b拥有相同的zone,且b上运行了一个pod,这个pod有一个label,key为
security
,value为S1
。那么我们创建如上的一个亲和性规则的3副本时,三个副本都会被调度到a或者b上。假如b上同时运行了一个pod,这个pod有一个label,key为security
,value为S2
,那么所有的副本都会调度到node a上。
taint toleration
node 可以被打上污点标记,并配置污点容忍策略。而pod的描述信息中如果包含了相同的污点容忍策略,就可以被调度到这个node上,反之则不可、或尽量不允许。
硬性规则
给node a 打上污点 name=huang, 策略为不可调度:
kubectl taint nodes a name=huang:NoSchedule
若我创建的pod中包含如下描述:
tolerations: - key: "name"operator: "Equal"value: "huang"effect: "NoSchedule"
则这个pod可以容忍有这类污点的node,即可以调度到node a,当然,也可以用如下的描述:
tolerations: - key: "name"operator: "Exist"effect: "NoSchedule"
类似的硬性规则体现在effect
字段中,还有NoExecute
,它比NoSchedule
更严格,不止pod不能调度上去,node上原有的pod如果不能容忍污点,就会被驱逐(eviction),配合字段tolerationSeconds
可以规定这些会被驱逐的pod能在node上呆多久。
软规则
除了NoExecute
,NoSchedule
,还有一条软规则:PreferNoSchedule
.配置effect=PreferNoSchedule
后,没有相关污点策略的pod会尽量避免调度到该node上。
转载于:https://blog.51cto.com/kusorz/2070627
Kubernetes的调度机制相关推荐
- 运行支持kubernetes原生调度的Spark程序
全栈工程师开发手册 (作者:栾鹏) 架构系列文章 Spark 概念说明 Apache Spark 是一个围绕速度.易用性和复杂分析构建的大数据处理框架.最初在2009年由加州大学伯克利分校的AMPLa ...
- cesium 渲染解析(Scene的调度机制)
在上一篇博文中,我们模拟了绘制太阳的方法,为地球添加了赤道平面, 美中不足的是,轨道平面常会被地球给挡住.下面我们详细分析scene的调度机制. 先看一下这个结构,Cesium把绘制命令(DrawCo ...
- Linux内核学习笔记十一——I/O层和I/O调度机制
一 块I/O基本概念 字符设备:按照字符流的方式被有序访问的设备.如串口.键盘等. 块设备:系统中不能随机(不需要按顺序)访问固定大小的数据片(chunk 块)的设备. 如:硬盘.软盘.CD-ROM驱 ...
- 定时任务重启后执行策略_quartz定时任务框架调度机制解析
quartz2.2.1集群调度机制调研及源码分析 引言 quartz集群架构 调度器实例化 调度过程 触发器的获取 触发trigger: Job执行过程: 总结: 附: 引言 quratz是目前最为成 ...
- quartz集群调度机制调研及源码分析---转载
quartz2.2.1集群调度机制调研及源码分析 引言 quartz集群架构 调度器实例化 调度过程 触发器的获取 触发trigger: Job执行过程: 总结: 附: 引言 quratz是目前最为成 ...
- 一个数据包大小是多少k_算法交流: 6046 数据包的调度机制 【2.6基本算法之动态规划】...
[题目描述] 6046 数据包的调度机制 By OIer14wa随着 Internet的迅猛发展,多媒体技术和电子商务应用日益广泛,Internet上的服务质量 (QoS,Qualityof Serv ...
- linux内核实时调度,基于Linux内核的实时调度机制的研究和实现
摘要: 实时操作系统在当前的各个领域得到广泛应用,越来越引起人们的重视.Linux操作系统的源代码开放.内核模块化设计及内核的高度可裁减性使其在嵌入式实时操作系统研究领域备受重视.但其面向通用多任务分 ...
- 某大型银行深化系统技术方案之十四:服务层之服务调度机制
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层 服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
- golang的goroutine调度机制
一直对goroutine的调度机制很好奇,最近在看雨痕的golang源码分析,(基于go1.4) 感觉豁然开朗,受益匪浅: 去繁就简,再加上自己的一些理解,整理了一下 ~~ 调度器 主要基于三个基本对 ...
- SystemVerilog调度机制与一些现象的思考
文章内容主要来自于以下文档,然后对自己平时遇到的一些现象作出了思考. 1.IEEE systemverilog.std.1800-2012 2.SystemVerilog Event Regions ...
最新文章
- oracle判断非空并拼接,oracle sql 判断字段非空,数据不重复,插入多跳数据
- (二)深入浅出图解Git,入门到精通(保姆级教程)
- 使用NGUINGUI的相关介绍
- 计算机专业建设思路和措施,计算机网络专业教学改革与建设思路措施
- ubuntu其中一个账户登录不了_ubuntu怎么在一个终端里以另一个帐户登录
- NIO与传统IO的区别(形象比喻)
- JS相关知识总结(一)
- 安装Ubuntu RISC V toolchain失败(网速、git配置原因)
- Java static , final和常量设计
- pandas DataFrame.shift()函数
- Coursera机器学习week11 单元测试
- 【java】序列化反序列化
- 使用计算机拍摄 制作电视和电影,视频制作毕业论文: 影视制作
- 计算个人所得税 (10 分)2019年个税新版规定:应纳税所得额为税前工资扣除五险一金,五险一金按工资22%比例计算。 个税起征点为5000元;
- x程序 Linux,使用XCB编写X Window程序(01):快速起步
- L1-009 N个数求和 (20 分)(C语言)(测试点3和测试点5)
- 交易结算金额一致性保证
- 基于Springboot+mybatis+mysql+html实现CRM智能办公系统
- SpringBoot通过自定义注解实现模板方法设计模式
- 3D角色 毛发制作 XGen关于导向的基本操作