一、前言

通过之前的学习，我们了解到k8s集群中最小工作单位是pod，对于k8s集群来说，一个pod的完整生命周期是由一系列调度策略来控制，这些调度策略具体是怎么工作的呢？本文将详细讨论下这个问题。

二、k8s调度策略简介

默认情况下，k8s集群中某个Pod在哪个Node节点运行，是由Scheduler组件采用相应的算法计算出来的。这个过程是不受人工控制的，从下图中通过Scheduler的位置也可以看出来；

但在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则；

三、k8s 四大调度策略

k8s提供了常用的4大调度规则，如下：

自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出；
定向调度：NodeName、NodeSelector；
亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity；
污点（容忍）调度：Taints、Toleration；

接下来，将结合实际操作对每种调度策略做详细的说明；

四、定向调度

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

4.1 基于NodeName定向调度

NodeName 用于强制约束将Pod调度到指定的Name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

如下，使用：kubectl get node 可以看到集群中的node节点的信息；

调度到指定 node

在当前目录下创建一个pod-nodename.yaml 的文件，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: pod-nodenamespace: default
spec:containers:- name: nginximage: nginx:1.17.1nodeName: izbp1hgw1v5d5y7bpvejtwz

执行下面的命令创建pod

kubectl create -f pod-nodename.yaml

通过查看pod详情也可以看到当前的Pod被调度到指定的节点上面了；

可能有的同学会怀疑这个Pod运行的节点是不是由于我们在yaml里面指定的配置才生效的，可以修改下下面这里的信息之后，再次创建Pod；

将下面这里的node信息修改为一个不存在的node名称；

我这里的效果是，直接报错了，就是对配置文件检查的时候就无法通过，网上有的模拟的效果是，创建之后查看Pod的状态一直是Pending的状态；

4.2 基于NodeSelector定向调度

NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的，也就是说，在pod创建之前，会由scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

NodeSelector 定向调度操作演示

给工作节点打一个标签

使用下面的命令对工作节点打标签

kubectl label nodes izbp1hgw1v5d5y7bpvejtwz nodeenv=test

创建一个Pod，使用上述的标签

再当前目录下创建一个pod-nodeselector.yaml 的文件，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: pod-nodeselectornamespace: default
spec:containers:- name: nginximage: nginx:1.17.1nodeSelector: nodeenv: test

使用下面的命令创建Pod

kubectl create -f pod-nodeselector.yaml

通过查看Pod的详细信息，可以看到当前的Pod被调度到被打上标签的工作节点上面了；

kubectl get pods pod-nodeselector -n default -o wide

五、亲和性调度

上面讲到了定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景。

基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。

5.1 亲和性调度（Affinity）分类

Affinity主要分为三类：

nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题；
podAffinity(pod亲和性) : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题；
podAntiAffinity(pod反亲和性) : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题；

关于亲和性(反亲和性)使用场景的说明：

亲和性

如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。

反亲和性

当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。

NodeAffinity 常用配置选项参数

pod.spec.affinity.nodeAffinityrequiredDuringSchedulingIgnoredDuringExecution  #Node节点必须满足指定的所有规则才可以，相当于硬限制nodeSelectorTerms  #节点选择列表matchFields   #按节点字段列出的节点选择器要求列表matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)key    #键values #值operat or #关系符 支持Exists, DoesNotExist, In, NotIn, Gt, LtpreferredDuringSchedulingIgnoredDuringExecution #优先调度到满足指定的规则的Node，相当于软限制 (倾向)preference   #一个节点选择器项，与相应的权重相关联matchFields   #按节点字段列出的节点选择器要求列表matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)key    #键values #值operator #关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Ltweight #倾向权重，在范围1-100。

关系符使用说明:

- matchExpressions:- key: nodeenv              # 匹配存在标签的key为nodeenv的节点operator: Exists- key: nodeenv              # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点operator: Invalues: ["xxx","yyy"]- key: nodeenv              # 匹配标签的key为nodeenv,且value大于"xxx"的节点operator: Gtvalues: "xxx"

5.2 NodeAffinity 操作演示

硬限制规则案例操作

在当前目录创建一个pod-nodeaffinity-required.yaml 配置文件，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: pod-affinitynamespace: default
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置nodeAffinity: #设置node亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制nodeSelectorTerms:- matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签- key: nodeenvoperator: Invalues: ["xxx","yyy","zzz"]

在当前集群下，我们并没有创建过xxx,yyy,zzz这样的标签，通过查询标签命令检查下集群中的标签

所以，理论上来讲，当执行Pod的创建命令之后，将会创建失败，执行创建命令后，看到下面的效果，说明Pod未能成功运行起来，这也就证明了上述这种选择器是一种硬限制规则；

也可以通过describe命令查看下创建失败的原因

kubectl describe pod pod-affinity -n default

如果换成我们上面创建的那个”test“标签，再看看效果如何，此时就可以成功运行Pod了；

软限制规则案例操作

上面演示了亲和性这种策略中的硬限制规则的效果，在某些场景下，假如集群中的资源充分，在不满足硬限制规则的情况下，还可以被自动调度，这时候就可以考虑使用软限制规则进行配置；

在当前目录下创建pod-neaffinity-preferred.yaml，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: affinity-preferrednamespace: default
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置nodeAffinity: #设置node亲和性preferredDuringSchedulingIgnoredDuringExecution: # 软限制- weight: 1preference:matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签(当前环境没有)- key: nodeenvoperator: Invalues: ["xxx","yyy","zzz"]

在当前的集群中，并不存在 xxx,yyy,zzz这样的标签，按照预期的猜想，软限制规则下，仍然可以成功创建出Pod；

运行下面的命令，创建Pod；

kubectl create -f pod-affinity-preferred.yaml

执行之后，我们发现，确实可以成功创建出Pod，就是说在这种软限制规则下，优先按照规则中的配置进行调度，如果没有找到，会按照自身的调度规则寻找合适的node进行Pod的创建；

NodeAffinity规则设置的注意事项

如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上；
如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可；
如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功；
如果一个pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化

5.3 PodAffinity

与NodeAffinity不同的是，NodeAffinity是以node节点为主体，而PodAffinity是站在Pod的视角来说的；

通俗来说，NodeAffinity表达的是创建Pod的时候，重点强调调度的策略与node的关联性，而PodAffinity强调的是与node中的Pod的关联性，弄清这一点对理解这个调度策略很有必要；

简而言之

PodAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照pod在一个区域的功能

PodAffinity 参数配置选项

pod.spec.affinity.podAffinityrequiredDuringSchedulingIgnoredDuringExecution  #硬限制namespaces       #指定参照pod的namespacetopologyKey      #指定调度作用域labelSelector    #标签选择器matchExpressions  #按节点标签列出的节点选择器要求列表(推荐)key    #键values #值operator #关系符 支持In, NotIn, Exists, DoesNotExist.matchLabels    #指多个matchExpressions映射的内容preferredDuringSchedulingIgnoredDuringExecution #软限制podAffinityTerm  #选项namespaces      topologyKeylabelSelectormatchExpressions  key    #键values #值operatormatchLabels weight #倾向权重，在范围1-100

关于topologyKey说明

topologyKey用于指定调度时作用域；
如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围；
如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分；

5.4 PodAffinity 操作演示

1）创建一个参照Pod

将这个参照Pod创建在某个工作节点上

在当前目录下，创建一个 affinity-target.yaml配置文件，配置内容如下

apiVersion: v1
kind: Pod
metadata:name: affinity-targetnamespace: defaultlabels:nodeenv: test #设置标签
spec:containers:- name: nginximage: nginx:1.17.1nodeName: izbp1hgw1v5d5y7bpvejtwz # 将目标pod名确指定到node1上

使用apply命令创建这个Pod，可以看到该Pod运行在指定的节点上；

2）创建一个自定义Pod

在当前目录下，创建一个自定义的affinity-required.yaml文件，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: affinity-requirednamespace: default
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置podAffinity: #设置pod亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签- key: nodeenvoperator: Invalues: ["xxx","yyy"]topologyKey: kubernetes.io/hostname

上面配置表达的意思是：由于设置的是硬限制，新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyy的pod在同一Node上，显然现在没有这样pod，只有一个nodeenv=test的，接下来，实际运行一下看看效果吧；

从下面的显示来看，Pod创建失败，

通过describe 命令检查下Pod创建失败的原因，大致的意思就是，当前集群下有2个可用节点，但由于master节点不允许调度，剩下的那个节点又不能匹配上Pod亲和性规则，所以创建失败；

为了让Pod能够匹配上目标Pod的亲和性规则，我们修改下配置文件，将test这个标签加入进来；

再次创建观察效果，这一次Pod就创建成功了；

5.5 PodAntiAffinity

pod反亲和性，顾名思义，上述的Pod亲和性说的是新的Pod以目标Pod为参照靠近，而反亲和性正好相反，尽量避免与目标Pod创建在同一个node；

简而言之

PodAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照pod不在一个区域中的功能。

PodAntiAffinity 操作演示

1）仍然以上面的这个affinity-target为目标Pod

2）创建配置文件，运行Pod

在当前目录下，创建antiaffinity-required.yaml配置文件，配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: antiaffinity-requirednamespace: default
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置podAntiAffinity: #设置pod亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配podenv的值在["pro"]中的标签- key: nodeenvoperator: Invalues: ["test"]topologyKey: kubernetes.io/hostname

然后执行创建，由于当前集群中的工作节点只有一个，而master节点默认不能被调度，所以创建失败（如果有多个node节点，将会被调度到其他节点上去）

六、污点调度

上面所说的调度方式其都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。这种调度策略即所谓的污点。

Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

6.1 污点格式

key=value:effect, key和value是污点的标签，effect描述污点的作用

其支持如下三个选项

PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度；
NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod；
NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离；

6.2 kubectl设置和去除污点的命令示例

# 设置污点
kubectl taint nodes node1 key=value:effect

# 去除污点
kubectl taint nodes node1 key:effect-

# 去除所有污点
kubectl taint nodes node1 key-

6.3 操作演示

依次模拟下面几个场景

1、为图中的工作节点设置一个污点: tag=test:PreferNoSchedule；然后创建pod1( pod1 理论上可以创建成功 );

test:PreferNoSchedule(尽量不要调度到该节点，没办法的情况下也可以调度)

2、修改图中的工作节点设置一个污点: tag=test:NoSchedule；然后创建pod2( pod1 正常， pod2 创建失败 )

test:NoSchedule(不允许调度到当前的节点)

3、修改图中的工作节设置一个污点: tag=test:NoExecute；然后创建pod3 ( 已存在的pod都失败 )

tag=test:NoExecute（新的Pod不允许调度进来，并驱逐老的Pod）

场景一：`PreferNoSchedule`

给工作节点设置污点标签

kubectl taint nodes izbp1hgw1v5d5y7bpvejtwz tag=test:PreferNoSchedule

通过节点的 describe命令可以检查节点的污点情况

在当前节点上启动一个Pod

kubectl run taint1-pod --image=nginx:1.17.1 -n default

总结：

从执行的结果来看，尽管给当前节点打上了污点，但是在这种策略下，创建Pod的时候仍然还是可以创建成功的；

场景二：`NoSchedule`

取消场景一中的污点，重新设置为NoSchedule

kubectl taint nodes izbp1hgw1v5d5y7bpvejtwz tag:PreferNoSchedule-

kubectl taint nodes izbp1hgw1v5d5y7bpvejtwz tag=test:NoSchedule

做完这两步操作后，可以看到之前的Pod仍然还在，此时我们再创建一个新的Pod，从下面的效果来看，新的Pod创建失败了

总结：

从效果来看，在NoSchedule这种策略下，已经运行的Pod继续运行，而新进来的Pod将会创建失败

场景三：NoExecute

取消场景二中的污点，重新设置为NoExecute

kubectl taint nodes izbp1hgw1v5d5y7bpvejtwz tag:NoSchedule-

重新创建一个Pod，观察效果，可以看到，之前的Pod已被驱逐，而新的Pod无法成功创建；

注意点

使用kubeadm搭建的集群，默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上

七、容忍（Toleration）调度

7.1 概述

上面介绍了污点的作用，我们可以在node上添加污点用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上去，这时候应该怎么做呢？这就要使用到容忍。

简而言之

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

紧接着上面污点最后的一个场景，我们给工作节点打上了NoExecute这也的标签，在这个标签下，理论上来说，新创建的Pod将无法在该节点创建出来；

如果在Pod上面配置容忍相关的规则，似乎就可以创建了；

7.2 操作过程演示

在当前目录下，创建pod-toleration.yaml文件

配置内容如下：

apiVersion: v1
kind: Pod
metadata:name: pod-tolerationnamespace: default
spec:containers:- name: nginximage: nginx:1.17.1tolerations:      # 添加容忍- key: "tag"        # 要容忍的污点的keyoperator: "Equal" # 操作符value: "test"    # 容忍的污点的valueeffect: "NoExecute"   # 添加容忍的规则，这里必须和标记的污点规则相同