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：污点，用在节点上的。