kubernetes高级调度02

一.taint（污点）和toleration（容忍）

• 在生产环境中，经常会有这样的需求:
  master 节点只部署系统组件容器，比如Calico、Metrics Server、Dashboard 等，不应该部署业务应用。
• 新添加节点不应该立即就允许部署业务容器，也就是新节点需要经过完整性及稳定性测试才可以
  被允许调度。
• 某些节点可能需要进行系统升级或者其他维护，可能会引起节点上的容器不可用，此时需要将该节点上的 Pod 漂移至其他节点，再进行维护。
• 有一些 GPU 服务器或其他专用节点服务器,除了指定的 Pod 之外,并不想让他们部署其他的 Pod.

1.污点和容忍基本概念

Taint(污点)作用在节点上，能够使节点排斥一类特定的 Pod.
Toleration(容忍)作用在 Pod 上，也就是可以兼容某类污点。

比如有一批 GPU 服务器只能部署要使用 GPU的 Pod。每个节点上都可以应用一个或多个 Taint，这表示对于那些不能容忍这些 Taint 的 Pod 是不能部署在该服务器上的。如果 Pod 配置了 Toleration，则表示这些 Pod 可以被调度到设置了 Taint 的节点上，当然没有设置 Taint 的节点也是可以部署的。

Taint(污点)和 Toleration(容忍)可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置nodeselector 将 pod 调度到具有匹配标签的节点上。

Taint 和 Toleration 相互配合,可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以(但不一定)被调度到具有匹配 taint 的节点

2.污点的使用

如果一个节点被标记为有污点，那么意味着不允许 pod 调度到该节点，除非 pod 也被标记为可以容忍
污点节点。

在使用 kubeadm 部署的 k8s 集群的时候应该会发现,通常情况下,应用是不会调度到 master 节点的。
因为 kubeadm 部署的 k8s 集群默认给 master 节点加了 Taints(污点)。

给节点 node01 增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 node1 这个节点。

node01是否为污点

若要移除该节点上的污点可以在后面加一个横杠

每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用效果，语法为 key=value:effect

当前taint effect支持一下三个选项

• NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上 ，不会驱逐已存在该节点上的 Pod。如果一个 pod 没有声明容忍这个 Taint,则系统不会把该 Pod 调度到有这个 Taint的 node 上。

• PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上 ，不会驱逐已存在该节点上的 Pod。这是 NoSchedule 的软限制版本,如果一个 Pod 没有声明容忍这个 Taint,则系统会尽量避免把这个 pod 调度到这一节点上去，但不是强制的。

• NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去，若节点上设置了污点并用的是 NoExecute 策略，node 节点上的 pod 会被全部驱逐，但是如果是 Deployment 或者 statefulset 资源类型，为了维持副本数量则会在别的Node 上再创建新的 Pod。

备注:
NoExecute 这个 Taint 效果对节点上正在运行的 pod 有以下影响:(1)没有设置 Toleration 的 Pod 会被立刻驱逐

(2)配置了对应 Toleration 的 pod，如果没有为 tolerationseconds 赋值，则会一直留在这一节点中
(3)配置了对应 Toleration 的 pod 且指定了 tolerationseconds 值，则会在指定时间后驱逐
tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间，即 60秒后该 pod 会被驱逐掉，默认的是一天。

3.容忍的定义

设置了污点的 Node 将根据 taint 的 effect: Noschedule、PreferNoSchedule、NoExecute 和 Pod之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。 但我们可以在 Pod 上设置容忍(Toleration)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。

4.示例

①设置污点

②创建测试模板

③运行pod

④在两个node上设置污点后，此pod无法调度到节点上

⑤修改测试模板

在 pod1.yaml 的基础上增加容忍度参数

tolerationseconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间,即 60 秒后该 pod 会被驱逐掉，默认的是一天。其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致。

⑥运行新的pod

⑦在设置容忍之后pod就调度到污点节点上

完成此实验后，将污点取消

5.容忍的基本用法

(1)容忍污点的条件
operator 的值为 Exists 将会忽略 value 值，即存在即可，为 Equal 时需要指定污点的 value.pod 的 Toleration 声明中的 key 和 effect 需要与 Taint 的设置保持一致,并且满足以下条件之一

①不完全匹配 operator值为Exists，这时无需指定value

tolerations:
- key: check
operator:"Exists'
effect: NoExecute

②完全匹配 operator值为Equal并且 value 相等(可以设置多个 tolerations)

tolerations :
key: checkoperator: Equal
value:mycheck
effect: NoExecute

③如果不指定operator默认的是Equal

tolerations :
key: check
value: mycheck
effect: NoExecute

（2）另外还有两种特例

①空的value effect 配合 Exists 操作符能够匹配所有的键和值，即能容忍所有污点。

tolerations:
operaton:"Exists'

②空的effect匹配所有的effect，容忍任何key名为check的污点

tolerations:
-key: check
operator:"Exists'

(3)一些特殊应用场景

#有多个 Master 存在时，为了防止资源浪费，可以将master 节点设置为PreferNoschedule 污点，让Pod 可在 Master 上临时创建:
kubectl taint node k8s-master node-role.kubernetes,io/master=:PreferNoschedule

#如果某个 Node 更新升级系统组件，为了防止业务长时间中断，可以先在该 Node 设置 NoExecute 污点，把该 Node 上的 Pod 都驱逐出去
kubectl taint node k8s-node01 check=mycheck:NoExecute

#此时如果别的 Node 资源不够用，可临时给 Master 设置 PreferNoschedule 污点，让 Pod 可在Master 上临时创建
kubectl taint node k8s-master node-role.kubernetes.io/master=:PreferNoschedule

#待所有 Node 的更新操作都完成后，再去除污点kubectl taint node node01 check=mycheck:NoExecute-

6.多污点与多容忍配置

系统允许在同一个 node 上设置多个 taint，也可以在 pod 上设置多个 TolerationKubernetes 调度器处理多个 Taint 和 Toleration 能够匹配的部分，剩下的没有忽略掉的Taint 就是对 Pod 的效果了。下面是几种特殊情况

• 如果剩余的 Taint 中存在 effect=NoSchedule，则调度器不会把该 pod 调度到这一节点上。

• 如果剩余的 Taint 中没有 NoSchedule 的效果，但是有 PreferNoschedule 效果，则调度器会尝试不会将 pod 指派给这个节点。

• 如果剩余 Taint 的效果有 NoExecute 的，并且这个 pod 已经在该节点运行，则会被驱逐;如果没有在该节点运行，也不会再被调度到该节点上。

二.警戒（cordon）和转移（drain）

1.设置警戒

警戒是指将 Node 标记为不可调度的状态这样就不会让新创建的 Pod 在此 Node 上运行
该 node 将会变为 SchedulingDisabled 状态

2.kubectl uncordon将node标记可调度状态

3.驱逐pod

kubectl drain 可以让 Node 节点开始释放所有 pod，并且不接收新的 pod 进程。drain 本意排水，意思是将出问题的 Node 下的 Pod 转移到其它 Node 下运行。
执行 drain 命令，会自动做了两件事情:
设定此 node 为不可调度状态(cordon)evict(驱逐)了 Pod

-ignore-daemonsets:无视 Daemonset 管理下的 Pod
--delete-local-data:如果有 mount local volume 的 pod，会强制杀掉该 pod
--force:强制释放不是控制器管理的 Pod，例如 kube-proxy

三.k8s亲和性和非亲和性

关于 K8S 对 Pod 的调度，通常情况下 Pod 被分配到哪些 Node 是不需要我们操心的，这个过程会由
scheduler 自动实现。但有时，我们需要让 Pod 按照我们的预想运行在 Node 上(例如某些应用“必须/或者尽量”跑在具有 SSD 存储的节点上，有些彼此相关的 Pod 应用应该跑在同一个节点上)。为此，k8s为我们提供了这样的策略，我们可以通过使用“亲和性/非亲和性”制定一些规则来实现我们的需求。

1:亲和性调度可以分成软策略和硬策略两种方式

硬策略:可以理解为必须，就是如果没有满足条件的节点的话，就不断重试直到满足条件为止。对应的配置规则为 requiredDuringSchedulingIgnoredDuringExecution。

软策略:可以理解为尽量，就是如果现在没有满足调度要求的节点的话，pod 就会忽略这条规则，继续完成调度的过程，说白了就是满足条件最好了，没有的话也无所谓。对应的配置规则为preferredDuringSchedulingIgnoredDuringExecution。

2.亲和性配置规则

分为 Node 亲和性、Pod 亲和性、Pod 反亲和性
nodeAffinity :节点亲和性，用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点
上的，这个是 Pod 与 Node 之间匹配规则的。

podAffinity : pod 亲和性，这个是 Pod 与 Pod 之间匹配规则的。
podAntiAffinity :pod 反亲和性，与 podAffinity 相反，用来指定 Pod 不要部署到哪些节点
上。

3.节点亲和性

节点的亲和性可以通过 pod.spec.affinity.nodeAffinity 字段定义，nodeAffinity 字段中支持使用 matchExpressions 属性构建更为复杂的标签选择器。

①设置节点标签

首先对两个 node 加标签，设置两个 node 标签分别为 node1 和 node2 。加标签的语法如下。kubectl label nodes =


备注:
如果需要重命名 node 标签，可以使用如下命令:[root@k8s-master ~]# kubectl label nodes k8s-node01 type=node1 --overwrite
如果要删除 node 标签(标签名为“type”)，可以使用如下命令:
[root@k8s-master ~l# kubectl label node k8s-node01 type-

②查看节点标签

③设置pod亲和性为type=node01

values:[“node01”] node1 为节点的标签，该 pod 要调度到标签为 node1 的节点，即 k8s-node01。

④部署pod并查看其信息

⑤设置pod亲和性为type=node02

4.节点软亲和性

节点软亲和性为节点选择提供了一种柔性的控制器逻辑，当条件不满足时，也能够接受被编排在其他不符合条件的节点之上。同时他还为每种倾向性提供了 weight 属性以便用于自定义优先级,范围是 1-100,越大越优先。

①为pod设置软亲和性

②部署pod并查看其信息

注意:
node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。
pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里。

5.Pod硬亲和度

出于某些需求，将一些 Pod 对象组织在相近的位置(同一节点、机架、区域等)，此时这些 pod 对象间的关系为 pod 亲和性。
Pod 的亲和性调度也存在硬亲和性和软亲和性的区别，他们表示的约束意义同节点亲和性相似。
Pod 硬亲和性调度也使用 requiredDuringSchedulingIgnoreDuringExecution 属性进行定义。
首先创建两个基础 Pod，并对它打标签，分别部署到 node01 和 node02 上。

①部署第一个基础pod，名字为pod4使其节点亲和到node01

pod04 的标签是 pod04，所在的节点标签是 node01

②部署并查看其信息

部署第二个基础pod名字为pod5节点硬亲和到node02

用pod硬亲和性创建一个亲和pod05的pod

matchExpressions 的 values 值为 pod 的标签。是哪个 pod 的标签，就亲和到哪个 pod 所在的 node 节
点
pod85 的标签是 pod05，所在的节点标签是 node02pod06 亲和了 pod05，于是也被调度到 node02

7.pod软亲和

Pod 软亲和调度使用方法与 Node软亲和调度方法类似。

①编辑pod07的pod

values:[“pod05”]是 pod05 的 pod 的标签values:[“pod04”]是 pod04 的 pod 的标签正则匹配了 pod 的标签“pod85”，带有 pod85 标签的 pod 是 pod85，该 pod 在 node02 上，于是 pod87的 pod 也调度到了 node02 上。

node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里

pod04 的标签是 pod04，所在的节点标签是 node01
pod05 的标签是 pod05，所在的节点标签是 node02pod07 软亲和了 pod85，所以也在 node2上

8.pod反亲和

査看 pod89 所在的节点,因为设置的反亲和 pod85,所以,pod85在 node82的话,pod89 就会在 node81
污点是阻止 Pod 调度的硬性条件,而亲和性是影响调度决策的软性指导。在 Kubernetes 调度过程中，污点的约束始终优先于亲和性的指导。
污点优先级高于亲和性:如果一个节点上有污点，而 Pod 没有相应的容忍度，那么无论亲和性规则如何，Pod 都不能被调度到该节点上。
亲和性不影响污点的约束:即使 Pod 的亲和性规则允许它被调度到某个节点，如果该节点上有污点而 Pod 没有容忍度，Pod 仍然不能被调度上去。