Kubernetes ：Taints(污点)和Tolerations(容忍)
目录
Taint
基本用法
effect 的取值
NoExecute
Toleration
基本用法
Toleration 几个特殊情况:
key 为空并且 operator 等于 Exists
effect 为空
TolerationSeconds
多污点与多容忍配置
kubernetes 内置taint行为
Taints(污点)和Tolerations(容忍)示例
专用节点
具有特殊硬件的节点
基于 taint 的驱逐
- Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，它们相互配合，可以用来避免 pod 被分配到不合适的节点上。
- 不同于Kubernetes 亲和性调度---是描述 pod 的属性，来声明此 pod 希望调度到哪类 nodes
Taint(污点)刚好相反，它是node 的一个属性，允许 node 主动排斥 pod 的调度。- 对应的 k8s 又给 pod 新增了配套属性
toleration(容忍)，用于表示这些 pod 可以（但不强制要求）被调度到具有相应 taints 的 nodes 上。这两者经常一起搭配，来确保不将 pod 调度到不合适的 nodes。
Taint
基本用法
- 设置污点: kubectl taint node [node] key=value:[effect]
其中 [effect] 可取值：[ NoSchedule | PreferNoSchedule | NoExecute ]:
- NoSchedule ：一定不能被调度。
- PreferNoSchedule：尽量不要调度。
- NoExecute：不仅不会调度，还会驱逐 Node 上已有的 Pod。
- 去除污点：kubectl taint node [node] key:[effect]-
effect 的取值
下面对 effect 的值作下简单说明：
- NoSchedule：如果一个 pod 没有声明容忍这个 Taint，则系统不会把该 Pod 调度到有这个 Taint 的 node 上
- PreferNoSchedule：NoSchedule 的软限制版本，如果一个 Pod 没有声明容忍这个 Taint，则系统会尽量避免把这个 pod 调度到这一节点上去，但不是强制的。
- NoExecute：定义 pod 的驱逐行为，以应对节点故障。
NoExecute
NoExecute 这个 Taint 效果对节点上正在运行的 pod 有以下影响：
- 没有设置 Toleration 的 Pod 会被立刻驱逐
- 配置了对应 Toleration 的 pod，如果没有为 tolerationSeconds 赋值，则会一直留在这一节点中
- 配置了对应 Toleration 的 pod 且指定了 tolerationSeconds 值，则会在指定时间后驱逐
从 kubernetes1.6 版本开始引入了一个 alpha 版本的功能，即把节点故障标记为 Taint（目前只针对 node unreachable 及 node not ready，相应的 NodeCondition "Ready" 的值为 Unknown 和 False）。
激活 TaintBasedEvictions 功能后（在–feature-gates 参数中加入 TaintBasedEvictions=true），NodeController 会自动为 Node 设置 Taint，而状态为 "Ready" 的 Node 上之前设置过的普通驱逐逻辑将会被禁用。
注意，在节点故障情况下，为了保持现存的 pod 驱逐的限速设置，系统将会以限速的模式逐步给 node 设置 Taint，这就能防止在一些特定情况下（比如 master 暂时失联）造成的大量 pod 被驱逐的后果。这一功能兼容于 tolerationSeconds，允许 pod 定义节点故障时持续多久才被逐出。
NoExecute效应由TaintBasedEviction控制，TaintBasedEviction是 Beta 版功能，自 Kubernetes 1.13 起默认启用。
Toleration
基本用法
你可以在PodSpec中为容器设定容忍标签。以下两个容忍标签都与上面的 kubectl taint 创建的污点“匹配”， 因此具有任一容忍标签的Pod都可以将其调度到“ node1”上：
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"tolerations:
- key: "key"
operator: "Exists"
effect: "NoSchedule"再看下 PodSpec 配置 Tolerations，其中的 key、value、effect 与 Node Taint 设置需要保持一致，operator 支持两类:
operator 的值为 Exists，这时无需指定 value
operator 的值为 Equal 并且 value 相等（如果不指定 operator，则默认值为 Equal）
Toleration 几个特殊情况:
key 为空并且 operator 等于 Exists
- 表示匹配了所有的 keys，values 和 effects。换句话说就是容忍了所有的 taints。
tolerations:
- operator: "Exists"effect 为空
- 则表示匹配所有的 effects（NoSchedule、PreferNoSchedule、NoExecute）
tolerations:
- key: "key"
operator: "Exists"TolerationSeconds
该值与 effect 为 NoExecute 配套使用。用来指定在 node 添加了 effect = NoExecute 的 taint 后，能容忍该 taint 的 pods 可停留在 node 上的时间。
例如:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
tolerationSeconds: 3600表示如果这个 pod 已经运行在 node 上并且该 node 添加了一个对应的 taint，那么这个 pod 将会在 node 上停留 3600 秒后才会被驱逐。但是如果 taint 在这个时间前被移除，那么这个 pod 也就不会被驱逐了。
多污点与多容忍配置
我们可以对 node 设置多个 taints，当然也可以在 pod 配置相同个数的 tolerations。影响调度和运行的具体行为，我们可以分为以下几类：
- 如果至少有一个
effect == NoSchedule的 taint 没有被 pod toleration，那么 pod 不会被调度到该节点上。- 如果所有
effect == NoSchedule的 taints 都被 pod toleration，但是至少有一个effect == PreferNoSchedule没有被 pod toleration，那么 k8s 将努力尝试不把 pod 调度到该节点上。- 如果至少有一个
effect == NoExecute的 taint 没有被 pod toleration，那么不仅这个 pod 不会被调度到该节点，甚至这个节点上已经运行但是也没有设置容忍该污点的 pods，都将被驱逐。
kubernetes 内置taint行为
kubernetes 1.6 版本，node controller 会跟进系统情况自动设置 node taint 属性。
内置 taint key 如下:
- node.kubernetes.io/not-ready: 节点尚未就绪
- node.kubernetes.io/unreachable: 节点无法被访问
- node.kubernetes.io/unschedulable: 节点不可调度
- node.kubernetes.io/out-of-disk: 节点磁盘不足
- node.kubernetes.io/memory-pressure: 节点有内存压力
- node.kubernetes.io/disk-pressure: 节点有磁盘压力
- node.kubernetes.io/network-unavailable: 节点网络不可用
- node.kubernetes.io/pid-pressure: 节点有 pid 压力
- node.cloudprovider.kubernetes.io/uninitialized: 云节点未初始化
- node.cloudprovider.kubernetes.io/shutdown: 云节点已下线
kubernetes 会通过 DefaultTolerationSeconds admission controller 为创建的 pod 添加两个默认的 toleration: node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable，并且设置 tolerationSeconds = 300。当然这个默认配置，用户可以自行覆盖。
这些自动添加的默认配置，确保 node 出现问题后，pod 可以继续在 node 上停留 5 分钟。
DefaultTolerationSeconds admission controller 设置的 tolerationSeconds 值，也可以由用户指定。
具体参考: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go
还有一个默认行为，就是 DaemonSet。
所有 DaemonSet 创建的 pod 都会添加两个 toleration:
node.alpha.kubernetes.io/unreachable和node.alpha.kubernetes.io/notReady。设置effect = NoExecute，并且不指定tolerationSeconds。
目的是确保在 node 出现 unreachable 或 notReady 的问题时，DaemonSet Pods 永远不会被驱逐。
Taints(污点)和Tolerations(容忍)示例
专用节点
如果你希望将一组节点专用于特定的用户，那可以将这些节点设置 taints,
kubectl taint nodes nodename dedicated=groupName:NoSchedule然后给这些应用的 pod 加入相应的 toleration，则带有合适 toleration 的 pod 就会被允许同使用其他节点一样使用有 taint 的节点。
如果你希望节点被专用并且确保服务仅使用这批节点，那么你还应该向这些 node 打上指定的标签 (dedicated=groupName)，并且为对应的 pods 设置 NodeAffinity，以控制 pods 只能跑到这批节点上。
具有特殊硬件的节点
有部分带有特殊硬件的节点，比如 GPU、FPGA 等，要确保不将不需要专用硬件的 pods 调度到这些节点。也可以和 专有节点 一样的方式设置 taints：
kubectl taint nodes test special=true:NoSchedule
kubectl taint nodes test special=true:PreferNoSchedule然后在 pod 中利用对应的 toleration 来保障特定的 pod 能够使用特定的硬件。然后同样的，我们也可以使用标签或者其他的一些特征来判断这些 pod，将其调度到这些特定硬件的服务器上。
建议还可以通过 Extended Resources 和 ExtendedResourceToleration admission controller 来更方便的调度依赖特殊硬件的 pods，而不需要手动添加容器的 toleration
基于 taint 的驱逐
之前说到，在节点故障时，可以通过 TaintBasedEvictions 功能自动将节点设置 Taint，然后将 pod 驱逐。
但是在一些场景下，比如说网络故障造成的 master 与 node 失联，而这个 node 上运行了很多本地状态的应用即使网络故障，也仍然希望能够持续在该节点上运行，期望网络能够快速恢复，从而避免从这个 node 上被驱逐。Pod 的 Toleration 可以这样定义：
tolerations:
- key: "node.alpha.kubernetes.io/unreachable"
operator:"Exists"
effect: "NoExecute"
tolerationSeconds: 6000对于 Node 未就绪状态，可以把 key 设置为 node.alpha.kubernetes.io/notReady- 如果没有为 pod 指定 node.alpha.kubernetes.io/noReady 的 Toleration，那么 Kubernetes 会自动为 pod 加入 tolerationSeconds=300 的 node.alpha.kubernetes.io/notReady 类型的 toleration。
- 如果没有为 pod 指定 node.alpha.kubernetes.io/unreachable 的 Toleration，那么 Kubernetes 会自动为 pod 加入 tolerationSeconds=300 的 node.alpha.kubernetes.io/unreachable 类型的 toleration。
这些系统自动设置的 toleration 用于在 node 发现问题时，能够为 pod 确保驱逐前再运行 5min。这两个默认的 toleration 由 Admission Controller "DefaultTolerationSeconds" 自动加入。
参考链接：https://kubernetes.io/zh/docs/concepts/configuration/taint-and-toleration/