Pod的调度

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做？这就要求了解Kubernetes对Pod的调度规则，Kubernetes提供了四大类调度方式。

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

一、定向调度

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

1、nodeName

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

首先创建一个pod-nodename.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
  namespace: dev
  labels:
    user: Negan
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1  # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
      ports:
        - name: nginx-port  # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口
          protocol: TCP # 端口协议
  nodeName: node1  # 指定调度到node1上

创建和查看Pod的状态，我们会发现Pod所在的Node节点就是我们指定的node1节点。

# 创建pod
kubectl create -f pod_nodename.yaml

# 查看
kubectl get pod pod-nodename -n dev -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
pod-nodename   1/1     Running   0          27s   10.244.1.18   node1   <none>           <none>

当然我们也可以将pod调度到不存在node上,pod肯定也是不能正常运行。

# 删除pod
kubectl delete -f pod_nodename.yaml

# 修改pod_nodename.yaml
# 将nodeName：node1 修改为node3 (node3不存在)

# 创建和查看状态
kubectl create -f pod_nodename.yaml

kubectl get pods pod-nodename -n dev -o wide

# 我们发现pod的状态时挂起状态
NAME           READY   STATUS    RESTARTS   AGE   IP       NODE    NOMINATED NODE   READINESS GATES
pod-nodename   0/1     Pending   0          6s    <none>   node3   <none>           <none>

2、nodeSelector

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

首先给node节点添加标签

kubectl label node node1 env=pro # 给node1添加标签为env=pro
kubectl label node node2 env=debug # 给node2添加标签为env=debug

# 可以看到我们已经添加上了相应的标签
kubectl get nodes --show-labels
NAME     STATUS   ROLES    AGE   VERSION   LABELS
master   Ready    master   2d    v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node1    Ready    <none>   2d    v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=pro,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2    Ready    <none>   2d    v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=debug,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

创建pod_nodeselector.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
  namespace: dev
  labels:
    user: Negan
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1  # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
      ports:
        - name: nginx-port  # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口
          protocol: TCP # 端口协议
  nodeSelector:
    env: debug

查看Pod的状态：

kubectl get pod pod-nodeselector -n dev -o wide

# 发现成功调度到node2上
NAME               READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
pod-nodeselector   1/1     Running   0          21s   10.244.2.20   node2   <none>           <none>

同样，我们如要调度要不存在的标签上，会发生什么情况：

# 删除pod
kubectl delete -f pod_nodeselector.yaml

# 修改pod_nodeselector.yaml文件
# 将debug改为debug1 

# 创建和查看
kubectl get pod pod-nodeselector -n dev -o wide
# pod的状态为挂起状态
NAME               READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
pod-nodeselector   0/1     Pending   0          24s   <none>   <none>   <none>           <none>

二、亲和性调度

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

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

Affinity主要分为三类：

• nodeAffinity（node亲和性）：以Node为目标，解决Pod可以调度到那些Node的问题。
• podAffinity（pod亲和性）：以Pod为目标，解决Pod可以和那些已存在的Pod部署在同一个拓扑域中的问题。
• podAntiAffinity（pod反亲和性）：以Pod为目标，解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。

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

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

1、nodeAffinity

查看nodeAffinity的可选配置项：

requiredDuringSchedulingIgnoredDuringExecution  #Node节点必须满足指定的所有规则才可以，相当于硬限制
    nodeSelectorTerms  #节点选择列表
      matchFields   # 按节点字段列出的节点选择器要求列表
      matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)
        key    #键
        values #值
        operator #关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt

preferredDuringSchedulingIgnoredDuringExecution #优先调度到满足指定的规则的Node，相当于软限制 (倾向)
    preference   #一个节点选择器项，与相应的权重相关联
      matchFields #按节点字段列出的节点选择器要求列表
      matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)
        key #键
        values #值
        operator #关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
    weight # 倾向权重，在范围1-100。

关系符的使用说明：

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

1.1、requiredDuringSchedulingIgnoredDuringExecution硬限制

创建pod_nodeaffinity_required.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
  namespace: dev
  labels:
    user: Negan
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1  # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
      ports:
        - name: nginx-port  # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口
          protocol: TCP # 端口协议
  affinity: # 亲和性设置
    nodeAffinity: # node亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # node节点必须满足所有规则
        nodeSelectorTerms: # 节点选择列表
          - matchExpressions:
              - key: env
                operator: In
                values: ["xxx","yyy"] # 需要满足其中一个

查看状态

kubectl get pods pod-nodeaffinity-required -n dev -o wide

# 我们发现STATUS为Pending,这也不难解释，我们的标签env对应的值没有xxx和yyy
NAME                        READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
pod-nodeaffinity-required   0/1     Pending   0          24s   <none>   <none>   <none>           <none>

使其正常调度

# 删除pod
kuebctl delete -f pod_nodeaffinity_required.yaml 

# 修改yaml文件，将“pro”或“debug”添加到values列表中,这里我添加了"pro"

# 创建
kubectl create -f pod_nodeaffinity_required.yaml 

# 查看
kubectl get pods pod-nodeaffinity-required -n dev -o wide
# 发现Pod成功被调度到node1节点上了
kubectl get pods pod-nodeaffinity-required -n dev -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
pod-nodeaffinity-required   1/1     Running   0          3s    192.168.166.131   node1   <none>           <none>

1.2、preferredDuringSchedulingIgnoredDuringExecution 软限制

创建pod_nodeaffinity_preferred.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-preferred
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: # 亲和性配置
    nodeAffinity: # node亲和性配置
      preferredDuringSchedulingIgnoredDuringExecution: # 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
        - preference: # 一个节点选择器项，与相应的权重相关联
            matchExpressions:
              - key: nodeenv
                operator: In
                values:
                  - "xxx"
                  - "yyy"
          weight: 1

查看Pod状态：

kubectl get pods pod-nodeaffinity-preferred -n dev -o wide

# 发现即使没有满足条件，pod也被正常调度了。
NAME                         READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
pod-nodeaffinity-preferred   1/1     Running   0          16s   192.168.104.2   node2   <none>           <none>

注意：

如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都满足，Pod才能运行在指定的Node上。

如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可。

如果一个nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有的才能匹配成功。

如果一个Pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的nodeAffinity的要求，则系统将忽略此变化。

2、podAffinity

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

查看PodAffinity的可选配置项

requiredDuringSchedulingIgnoredDuringExecution  # 硬限制
  namespaces # 指定参照pod的namespace
  topologyKey # 指定调度作用域
  labelSelector # 标签选择器
    matchExpressions  # 按节点标签列出的节点选择器要求列表(推荐)
      key    #  键
      values # 值
      operator # 关系符 支持In, NotIn, Exists, DoesNotExist.
    matchLabels    # 指多个matchExpressions映射的内容  

preferredDuringSchedulingIgnoredDuringExecution # 软限制
  podAffinityTerm  # 选项
    namespaces
    topologyKey
    labelSelector
       matchExpressions
          key   #  键
          values # 值
          operator
       matchLabels
  weight 倾向权重，在范围1-100

topologyKey用于指定调度的作用域，例如:

如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围。

如果指定为beta.kubernetes.io/os，则以Node节点的操作系统类型来区分。

案例

创建参照的pod，编写pod-podaffinity-target.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-target
  namespace: dev
  labels:
    user: Negan
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1  # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
      ports:
        - name: nginx-port  # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口
          protocol: TCP # 端口协议
  nodeName: node1 # 将pod定向调度到node1节点上

查看目标pod的运行状态：

kubectl get pods pod-podaffinity-target -n dev -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
pod-podaffinity-target   1/1     Running   0          37s   192.168.166.134   node1   <none>           <none>

发现如我们预期那样，参照pod运行在node节点上。

2.1、requiredDuringSchedulingIgnoredDuringExecution

创建目标pod,将其调度到参照pod所在的节点上，编写pod-podaffinity-requred.yaml文件 ：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-requred
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: # 亲和性配置
    podAffinity: # Pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        - labelSelector:
            matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在同一个Node上
              - key: user
                operator: In
                values:
                  - "Negan"
                  - "yyy"
          topologyKey: kubernetes.io/hostname

查看目标pod运行状态：

kubectl get pods pod-podaffinity-requred -n dev -o wide
NAME                      READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
pod-podaffinity-requred   1/1     Running   0          25s   192.168.166.135   node1   <none>           <none>

发现目标pod和参考pod运行在同一个Node节点上。

2.2、preferredDuringSchedulingIgnoredDuringExecution软限制

编写pod-podaffinity-requred.yaml文件，我们将pod调度到不满足调度条件的node上，看是否能成功 ：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-prefer
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: # 亲和性配置
    podAffinity: # Pod亲和性
      preferredDuringSchedulingIgnoredDuringExecution: #软限制
        - podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: user
                  operator: In
                  values:
                    - "xxx"
                    - "yyy"
            topologyKey: kubernetes.io/hostname
          weight: 1

查看pod的状态：

kubectl get pod -n dev pod-podaffinity-prefer -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
pod-podaffinity-prefer   1/1     Running   0          21s   192.168.104.4   node2   <none>           <none>

发现pod在不满足给定调度条件情况下，任然可以调度，pod被调度到了node2上。

3、podAntiAffinity

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

其配置方式和podAffinity一样，此处不做详细解释。

这里我们继续使用上面的参照pod做演示。

创建pod-podantiaffinity-requred.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podantiaffinity-requred
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: # 亲和性配置
    podAntiAffinity: # Pod反亲和性
      requiredDuringScheduAlingIgnoredDuringExecution: # 硬限制
        - labelSelector:
            matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在不在同一个Node上
              - key: user
                operator: In
                values:
                  - "Negan"
                  - "yyy"
          topologyKey: kubernetes.io/hostname

查看pod状态:

kubectl get pods pod-podantiaffinity-requred -n dev -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
pod-podantiaffinity-requred   1/1     Running   0          27s   192.168.104.5   node2   <none>           <none>

发现，目标pod被调度到node2节点上，我们的参照pod被调度在node1上，说明和我们预期的效果一致。

三、污点和容忍

1、污点

前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否运行Pod调度过来。

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

污点的格式为：key=value:effect，key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

​ 1、PreferNoSchedule：Kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可以调度。

​ 2、NoSchedule：Kubernetes将不会把Pod调度到具有该污点的Node上，但是不会影响当前Node上已经存在的Pod。

​ 3、NoExecute：Kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已经存在的Pod驱逐。

污点相关语法:

• 设置污点

  kubectl taint node xxx key=value:effect
  

• 去除污点

  kubectl taint node xxx key:effect-
  

• 去除所有污点

  kubectl taint node xxx key-
  

• 查看指定节点上的污点

  kubectl describe node 节点名称
  

下面通过案例来进行演示污点。

为了方便操作，先暂时停掉node2节点。

在node2上执行下面命令，停掉node2:

kubeadm reset

在master节点上进行查看节点状态：

kubectl get node
NAME     STATUS     ROLES    AGE    VERSION
master   Ready      master   147m   v1.18.0
node1    Ready      <none>   146m   v1.18.0
node2    NotReady   <none>   146m   v1.18.0

发现node2节点已经停掉了，接着我们为node1添加PreferNoSchedule污点：

kubectl taint node node1 tag=Negan:PreferNoSchedule

创建一个pod1,并查看pod的状态：

kubectl get pod pod1 -n dev -o wide

NAME   READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          16s   192.168.166.136   node1   <none>           <none>

发现pod1正常运行，并且被调度到node1节点上。

给node1更换NoSchedule污点

# 去掉node1上原有的污点
kubectl taint node node1 tag:PreferNoSchedule-

# 添加新污点
kubectl taint node node1 tag=Negan:NoSchedule

创建pod2,正常情况下，新创建的pod不能被调度到node1上，原有的pod不受影响。

# 创建pod2
kubectl run pod2 --image=nginx:1.17.1 -n dev

# 查看状态，与我们预期的结果一致
kubectl get pod -n dev -o wide
NAME                          READY   STATUS        RESTARTS   AGE    IP                NODE
...... 省略部分内容
pod1                          1/1     Running       0          6m5s   192.168.166.136   node1    <none>           <none>
pod2                          0/1     Pending       0          14s    <none>            <none>   <none>           <none>

给node1更换NoExecute污点：

# 给node1更换污点NoExecute
kubectl taint node node1 tag:NoSchedule-
kubectl taint node node1 tag=Negan:NoExecute

查看namespace=dev下所有pod的状态：

kubectl get pod -n dev
NAME                          READY   STATUS        RESTARTS   AGE
pod-nodeaffinity-preferred    1/1     Terminating   1          128m
pod-nodeaffinity-required     0/1     Terminating   1          132m
pod-podaffinity-prefer        1/1     Terminating   0          36m
pod-podaffinity-requred       0/1     Terminating   0          85m
pod-podaffinity-target        0/1     Terminating   0          90m
pod-podantiaffinity-requred   1/1     Terminating   0          26m
pod1                          0/1     Terminating   0          12m
pod2                          0/1     Terminating   0          6m13s

发现所有的Pod的状态都变为了Terminating。

说明

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

2、容忍

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

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

容忍详细配置：

kubectl explain pod.spec.tolerations
......
FIELDS:
  key       # 对应着要容忍的污点的键，空意味着匹配所有的键
  value     # 对应着要容忍的污点的值
  operator  # key-value的运算符，支持Equal和Exists（默认）
  effect    # 对应污点的effect，空意味着匹配所有影响
  tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间

当operator为Equal的时候，如果Node节点有多个Taint，那么Pod每个Taint都需要容忍才能部署上去。

当operator为Exists的时候，有如下的三种写法：

• 容忍指定的污点，污点带有指定的effect：

    tolerations: # 容忍
      - key: "tag" # 要容忍的污点的key
        operator: Exists # 操作符
        effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同
  

• 容忍指定的污点，不考虑具体的effect：

    tolerations: # 容忍
      - key: "tag" # 要容忍的污点的key
        operator: Exists # 操作符
  

• 容忍一切污点（慎用）：

   tolerations: # 容忍
      - operator: Exists # 操作符
  

在上面的污点示例中，已经给node1打上了NoExecute的污点，此时任何Pod是调度不上去的，可以通过在Pod中添加容忍，将Pod调度上去。

创建pod-toleration.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-toleration
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  tolerations: # 容忍
    - key: "tag" # 要容忍的污点的key
      operator: Equal # 操作符
      value: "Negan" # 要容忍的污点的value
      effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同

查看pod状态：

kubectl get pods pod-toleration -n dev
NAME             READY   STATUS    RESTARTS   AGE
pod-toleration   1/1     Running   0          47s