其他分享
首页 > 其他分享> > 13.调度器、预选策略及优选函数、高级调度方式

13.调度器、预选策略及优选函数、高级调度方式

作者:互联网

参见:调度器、预选策略与优选函数 https://www.cnblogs.com/weiyiming007/p/10560518.html

一、前言

master上运行着三个最核心的组件,apiserver、scheduler、controller manager。此外,master还依赖于ectd存储节点,最好ectd是有冗余能力的集群。

1、调度器(scheduler)

master上的scheduler控制着pod运行在哪个node上,默认用的default-scheduler(用describe时详情里可以看到用的哪个调度器);

调度器的调度信息存储在master上的etcd里面,apiserver负责和etcd通信;

kubelet运行在node节点上,监控着Node节点上的pod状态,并参与pod的创建等工作;

kube-proxy也运行在node节点上,它监控着service资源的变动, 然后将其在当前节点上创建为iptables或ipvs规则。Kube-proxy是管理service的组件;

kubelet和kube-proxy都要连接master上的apiserver去获取定义信息;

2、调度过程

预选策略(predicate):先排除那些完全不符合此pod运行法则的节点,有两个维度来排除,一个是最低资源需求(request),即节点必须满足此Pod的最低资源;第二个是资源限额(limit),即当前节点最多能给pod提供的资源;

优选(priority):在符合节点找到最佳匹配的节点;

选定(select):把pod绑定到优选的节点上,如果有多个最佳节点,就会随机选一个;

3、K8S的高级调度方式

nodeAffinity:表示node亲和性调度,表示这个pod对这个节点有一定的倾向性。我们通过nodeselector来完成这类调度;

podAffinity或podAntiAffinity:pod亲和性或者pod反亲和性调度,有时我们期望某些Pod运行在同一个节点上或者是相邻的节点上,或者我们期望某些Pod不要运行在某些节点上;

taints和tolerations:污点和污点容忍调度:可以在某些节点上打上污点,表示这些节点不让pod在其上面运行。容忍某节点上污点的子集,则可以该Pod可被调度到该节点上。taints是定义在节点之上的,tolerations是定义在pod之上的。

一般是基于最大资源的空闲率来调度。

二、预选策略

1.源码

https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/algorithm/predicates/predicates.go   # 预选策略很多,参见源码。

定义的策略很多,但是很多策略默认是没有启用的,可以手动配置启用。

2.常用的预选策略

1、CheckNodeCondition:表示检查是否可以在节点磁盘、网络不可用,或未准备好的前提下,能够把pod调度到上去。

2、GeneralPredicates:通用预选策略,不是一个策略,包含好几个预选策略:

       HostName:表示如果pod定义了hostname属性(pod.spec.hostname),则检查节点的名字跟pod的hostname是否相匹配,但这里并不是定义这个pod必须运行在这些节点上;

       PodFitsHostPorts:如果节点定义了hostport属性(pod.spec.containers.ports.hostPort),表示指定在节点的哪个端口上。如果这个节点的端口被占用了,那么这个节点就不适合运行这个pod;

       MatchNodeSelector:检查pods.spec.nodeSelector这个字段你是否定义了,运行在携有这有这些标签选择器的节点上;没有对应的node,则pod无法运行。

       PodFitsResources:检查节点是否有足够的资源来支持这个pod运行;

3、NoDiskConfict:检查Pod所请求的存储卷类型在此节点上是否可用。比如需要glusterfs类型的资源,但该节点不能挂在该类型资源。NoDiskConfict调度策略默认没有启用。

4、PodToleratesNodeTaints:如果Pod定义了Tolerates(容忍度),即pods.spec.tolerations,那么就检查Pod上的spec.tolerations可容忍的污点是否完全包含节点上的污点,如果是,表示这个节点可以被选定;

5、PodToleratesNodeNoExecuteTaints:检查pod是否容忍节点上有NoExecute污点。NoExecute污点:如果一个pod上运行在一个没有污点的节点上,后来这个节点又给加上污点了,那么NoExecute表示这个新加污点的节点会去除其上正在运行的pod;此调度策略默认没有启用;

6、CheckNodeLabelPresence:检查节点上指定标签的存在性,如果节点有pod指定的标签,那么这个节点就被选中。 此调度策略默认没有启用;

7、CheckServiceAffinity:根据当前Pod对象所属的Service已有的其他Pod对象。一个service下可以有多个pod,比如这些pod都运行在1、2、3机器上,而没有运行在4、5、6机器上,那么CheckServceAffinity就表示新加入的pod都集中运行在1、2、3机器上,这样集中好处是一个service下pod之间内部通信的效率变高了。 这个策略默认是没有启用的。

8、CheckVolumeBinding:检查节点上的pvc是否被别的pod绑定了;

9、NoVolumeZoneConflict:区域限制的前提下,检查节点上的pod是否与pod的需求冲突;

10、CheckNodeMemoryPressure:检查节点内存是否存在压力;

11、CheckNodePIDPressure:检查节点pid数量是否压力过大,但一般pid是可以重复使用的;

12、CheckNodeDiskPressure:检查内存/磁盘 IO是否压力过大;

13、MatchInterPodAffinity:检查Pod是否满足亲和性或者反亲和性;

14、MaxCSIVolumeCountPred:检查节点上挂载的附加存储的数量是否超出了最大的设定值。

 

pod在调度的时候,启用的所有预选策略要逐一评估。(都要满足,一票否决)

三、优选函数

1.源码

https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler/algorithm/priorities

https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/algorithm/priorities/priorities.go

2.常用的优选函数

每一个优选函数的最大得分是10分。(得分范围是0-10)

1、LeastRequest:最少请求,空闲比例。对cpu来说,用cpu((capacity-sum(requested))*10/capacity)方式进行评估,得分最高的胜出;内存同样。(cpu得分+mem得分)/2=优选函数得分

2、BalanceResourceAllocation:均衡资源的使用方式,表示以cpu和内存占用率的相近程度(均衡)作为评估标准,二者占用越接近,得分就越高,得分高的胜出。

3、NodePreferAvoidPods:看节点是否有注解信息"scheduler.alpha.kubernetes.io/preferAvoidPods"。没有这个注解信息,说明这个节点是适合运行这个pod的,得分为10。优先级很高。

4、TaintToleration:将pod对象的spec.toleration与节点的taint列表项进行匹配度检查,匹配的条目越多,得分越低;

5、SelectorSpreading:查找当前pod对象对应的service,statefulset,replicatset等所匹配的标签选择器,在节点上运行的带有这样标签的pod越少得分越高。 这就是说我们要把同一个标签选择器下运行的pod散开(spreading)到多个节点上;

6、InterPodAffinity:遍历Pod对象亲和性的条目,并将那些能够匹配到节点权重相加,值越大的得分越高,得分高的胜出;

7、NodeAffinity:根据pod对象中的nodeselector,对节点进行匹配度检查,能够成功匹配的数量越多,得分就越高;

8、MostRequest:表示尽可能的把一个节点的资源先用完,这个和least_requested相反,二者不能同时使用;默认未启用;

9、NodeLabel:根据节点是否拥有标签,不关注标签值,来评估分数;默认未启用;

10、ImageLocality:表示根据满足当前pod运行需要的已有镜像体积大小之和来选择节点的;默认未启用。

 

启用的优选函数会逐一评估,最后得分相加,根据最终得分来优!!

四、高级调度设置方式

两类调度方式

节点选择器:nodeSelector,nodeName

节点亲和调度:nodeAffinity

(一)、节点选择器nodeSelector(强约束)

[root@master ~]# kubectl explain pod.spec.nodeSelector

 

Pod处于Pending状态,因为调度失败,没有节点拥有disk:ssh标签。

[root@master ~]# kubectl label node node2 disk=ssd  # 给node2打上需要的标签。

可以看到刚才Pending的pod运行到了节点2上。

(二)、节点亲和性调度nodeAffinity

[root@master ~]# kubectl explain pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution:硬亲和性,必须满足
preferredDuringSchedulingIgnoredDuringExecution:软亲和性,不是必须,尽量满足,优先运行在满足条件的节点上。

软亲和性和硬亲和性资源清单定义不相同,不能单独改个单词就是。

1、硬亲和性

[root@master ~]# kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms

 

目前没有节点拥有zone=foo或者zone=bar。

[root@master ~]# kubectl label node node1 zone=foo  #给node1打个标签

Pod状态变为Running。

2、软亲和性

[root@master ~]# kubectl label node node1 zone-  # 先删除node1上的zone标签

目前是没有节点有拥有pod所需要的标签的,但是Pod一经创建马上运行,因为软亲和性,满足最好,不能满足也能将就。

三、Pod亲和性调度podAffinity,podAntiAffinity

比如在机房中,我们可以将一个机柜中的机器都打上标签,让pod调度的时候,对此机柜有亲和性;或者将机柜中某几台机器打上标签,让pod调度的时候,对这几个机器有亲和性;

通过节点亲和性,也能让一组pod运行在一起,但需要对节点进行精心编排,节点拥有的标签,想在一起pod使用相同的标签选择器,不想在一起的pod使用不同的标签选择器,比较麻烦。

Pod亲和性,第一个Pod随机调度,后面的Pod都以此为标准,运行在相近节点上,不需要考虑节点标签配置。但仍需要有一个逻辑条件预先设置好哪些节点是属于相近节点,同一位置,让pod去判断。

1、Pod亲和性podAffinity

[root@master ~]# kubectl explain pod.spec.affinity.podAffinity
preferredDuringSchedulingIgnoredDuringExecution:软亲和性
requiredDuringSchedulingIgnoredDuringExecution:硬亲和性

硬亲和性

[root@master ~]# kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

第二个Pod定义的podAffinity意思为:当前这个pod要跟一个有着标签app=myapp(要和上面pod-first的metadata里面的标签一致)的pod在一起。

topologyKey: kubernetes.io/hostname意思为:节点标签kubernetes.io/hostname相同的为相近节点。

由于定义的是硬亲和性,如果调度器找不到运行着app=myapp标签资源的节点,则Pod状态应该是Pending。

注意:要考虑到所有存在此标签的Pod,预期结果不同可能是因为当前名称空间已经存在app=myapp标签的Pod。

软亲和性

类似,不多介绍。

2、Pod反亲和性podAntiAffinity

[root@master ~]# kubectl explain pod.spec.affinity.podAntiAffinity
preferredDuringSchedulingIgnoredDuringExecution:软亲和性
requiredDuringSchedulingIgnoredDuringExecution:硬亲和性

资源清单定义类似于podAffinity。

硬亲和性

 

这样展现出来的效果不明显,如果只有一个节点可用的话,应该是第二个Pod会Pending。

再次实验:

[root@master ~]# kubectl label nodes node1 zone=foo
[root@master ~]# kubectl label nodes node2 zone=foo 
# 给node1,node2打标签,这样node1,node2以此为标签属于一组相近节点,创建Pod时以zone为topologyKey。

与预期结果相符,调度失败提示也很明显。

软亲和性

类似,不过多实验。

四、污点调度

给节点选择了让哪些Pod运行的权利。

污点(taint)定义在节点上。

Tolerations:定义在pod上,定义容忍度。

[root@master ~]# kubectl get node node1 -o yaml
[root@master ~]# kubectl explain node.spec.taints

在Pod上定义容忍度有两种方式

[root@master schedule]# kubectl explain deployment.spec.template.spec.tolerations.operator
等值比较Equal: key,value,effect完全匹配
存在性判断Exists:key,effect完全匹配,value可以为空,不关注。

逐一匹配节点上的污点是否被容忍,只要有一个污点没有被容忍,并且effect为NoSchedule,则一定不能被调度过来。

[root@master ~]# kubectl describe node master  #一般pod不被调度到master的原因是Master上存在污点。

1、node.spec.taints.effect

taints上的effect定义对Pod的排斥效果:

NoSchedule:仅影响调度过程,对现存pod不产生影响,不能容忍就不能调度过来。

PreferNoSchedule:仅影响调度过程,不能容忍就不能调度过来,但是实在没办法也是能调度过来的。对节点新加了污点,那么对节点上现存的pod没有影响。

NoExecute:既影响调度过程,也影响现存的Pod对象。不容忍污点的Pod对象将被驱逐。

2、定义污点及容忍度

定义污点:

[root@master ~]# kubectl taint --help
[root@master schedule]# kubectl taint node node1 node-type=production:NoSchedule #给node1打上污点

所有的pod都被调度到了node2,因为pod不能容忍污点。在node2上也打上污点,并且effect为NoExecute,则已调度的Pod会被驱逐,然后因为所有节点上都有pod容忍不了的污点,pod就pending了。效果如下:

[root@master schedule]# kubectl taint node node2 node-type=dev:NoExecute

 

定义容忍度:

[root@master schedule]# kubectl explain pod.spec.tolerations
[root@master schedule]# kubectl explain deployment.spec.template.spec.tolerations

在Pod上定义容忍度(容忍node-type=production:NoSchedule)后,之前Pending的pod被调度到了node1上,符合预期。

修改资源清单,定义容忍node-type的所有effect,则pod能容忍node1,node2上的node-type污点,不管effect是什么。

注意:

       容忍度定义,等值比较(Equal)必须key,value,effect三者完全相匹配;如果effect,key定义为空,代表匹配所有的effect和key

       修改了资源清单的容忍度,Pod会被重新调度。

[root@master ~]# kubectl describe nodes node1 |grep -E '(Roles|Taints)'  #查看节点上的污点
[root@master ~]# kubectl taint node node1 node-type-    #删除节点上的污点
[root@master ~]# kubectl taint node node2 node-type-

五、Tips:

Protocol Buffer:组件之间内部对象序列化格式。

Json:资源对象序列化格式。

键值数据对:

       Labels:标签

       Annotations:注解

       Taints:污点,用在节点上的。

标签:13,预选,亲和性,调度,master,Pod,节点,pod
来源: https://www.cnblogs.com/cmxu/p/12255993.html