linux数据污点标记,Taints和Tolerations（污点和容忍）

Taints和Tolerations(污点和容忍)

上面介绍的NodeAffinity节点亲和性，是在pod上定义的一种属性，是pod能够被调度到某些node上运行(优先选择或强制要求)。Taint则正好相反，使用kubectl taint命令可以给某个Node节点设置污点，Node被设置上污点之后就和Pod之间存在了一种相斥的关系，可以让Node拒绝Pod的调度执行，甚至将Node已经存在的Pod驱逐出去。

Taint需要和Toleration配合使用，让pod避开那些不适合的node。在node上设置一个或多个Taint之后，除非pod明确声明能够容忍这些污点，否则无法在这些node上运行。Toleration是pod的属性，让pod能够(注意，只是能够，而非必须)运行在标注了Taint的node上。

每个污点的组成如下：

key=value:effect

每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。

当前 taint effect 支持如下三个选项：

NoSchedule ：表示k8s不会将新的不能容忍的Pod调度到具有该污点的Node上，但是之前运行在node节点中的Pod不受影响

PreferNoSchedule ：表示k8s将尽量避免将Pod调度到具有该污点的Node上

NoExecute ：表示k8s不会将新的不能容忍的Pod调度到具有该污点的Node上，同时会将Node上已经存在的Pod驱逐出去

可以用kubectl taint 命令为Node设置Taint信息：

kubectl taint nodes node1 env=pro:NoSchedule

查看所有Node上的污点

kubectl describe no|grep -e Hostname -e Taints|grep -v none|grep -A 1 "Taints"

查看指定node上的污点

kubectl describe no nodename|grep Taints

删除taint:

kubectl taint nodes node1 env:NoSchedule-

这个设置为node1加上一个Taint。该Taint的键为key，值为value，Taint的效果是NoSchedule。这意味着除非pod明确声明可以容忍这个Taint，否则就不会被调度到node1上。

然后，需要在pod上声明 Toleration。下面的两个Toleration都被设置为可以容忍(Toleration)具有该Taint的node，使得pod能够被调度到node1上：

apiVersion: v1

kind: Pod

metadata:

name: pod-toleration

spec:

tolerations:

- key: "key"

operator: "Equal"

value: "value"

effect: "NoSchedule"

containers:

- name: pod-toleration

image: gcr.io/google_containers/pause:2.0

或者

tolerations:

- key: "key"

operator: "Exists"

effect: "NoSchedule"

pod的toleration声明中的key和effect需要与Taint的设置保持一致，并且满足以下条件之一。operator的值是Exists(无需指定value)

operator的值是Equal 并且value相等。

如果不指定operator，则默认值为Equal。

另外，有如下两个特例：空的key配合Exists操作符能够匹配所有的键和值。

空的effect匹配所有的effect。

系统允许在同一个Node上设置多个Taint，也可以在Pod上设置多个Toleration。Kubernetes调度器处理多个Taint和Toleration的逻辑顺序为：首先列出节点中所有的Taint，然后忽略Pod的Toleration能够匹配的部分，剩下的没有忽略的Taint就是对Pod的效果了。下面是几种特殊情况。

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

如果在剩余的Taint中没有NoSchedule效果，但是有PreferNoSchedule效果，则调度器会尝试不把这个Pod指派给这个节点。

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

例如，我们这样对一个节点进行Taint设置：

kubectl taint nodes node1 key1=value1:NoSchedule

kubectl taint nodes node1 key1=value1:NoExecute

kubectl taint nodes node1 key2=value2:NoSchedule

然后在Pod上设置两个Toleration:

tolerations:

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoSchedule"

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoExecute"

这样的结果是该Pod无法被调度到node1上，这是因为第3个Taint没有匹配的Toleration。但是如果该Pod已经在node1上运行了，那么在运行时设置第3个Taint，它还能继续在node1上运行，这是因为Pod可以容忍前两个Taint。

一般来说，如果给Node加上effect=NoExecute的Taint，那么在该Node上正在运行的所有无对应Toleration的Pod都会被立刻驱逐，而具有相应Toleration的Pod永远不会被驱逐。不过，系统允许给具有NoExecute效果的Toleration加入一个可选的tolerationSeconds字段，这个设置表明Pod可以在Taint添加到Node之后还能在这个Node上运行多久(单位为s)：

tolerations:

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoExecute"

tolerationSeconds: 3600

上述定义的意思是，如果Pod正在运行，所在节点都被加入一个匹配的Taint，则这个Pod会持续在这个节点上存活3600s后被逐出。如果在这个宽限期内Taint被移除，则不会触发驱逐事件。

Taint和Toleration是一种处理节点并且让Pod进行规避或者驱逐Pod的弹性处理方式，下面列举一些常见的用例。

1.专用节点(dedicated)

如果想要拿出一部分节点专门给一些特定应用使用，则可以为节点添加这样的Taint：

kubectl taint nodes nodename dedicated=groupName:NoSchedule

然后给这些应用的Pod加入对应的Toleration。这样，带有合适Toleration的Pod就会被允许同使用其他节点一样使用有Taint的节点。

通过自定义Admission Controller也可以实现这一目标。如果希望让这些应用独占一批节点，并且确保它们只能使用这些节点，则还可以给这些Taint节点加入类似的标签dedicated=groupName，然后Admission Controller需要加入节点亲和性设置，要求Pod只会被调度到具有这一标签的节点上。

2.具有特殊(special)硬件设备的节点

在集群里可能有一小部分节点安装了特殊的硬件设备(如GPU芯片)，用户自然会希望把不需要占用这类硬件的Pod排除在外，以确保对这类硬件有需求的Pod能够被顺利调度到这些节点。

可以用下面的命令为节点设置Taint：

kubectl taint nodes nodename special=true:NoSchedule

kubectl taint nodes nodename special=true:PreferNoSchedule

然后在Pod中利用对应的Toleration来保障特定的Pod能够使用特定的硬件。

和上面的独占节点的示例类似，使用Admission Controller来完成这一任务会更方便。例如，Admission Controller使用Pod的一些特征来判断这些Pod，如果可以使用这些硬件，就添加Toleration来完成这一工作。要保障需要使用特殊硬件的Pod只被调度到安装这些硬件的节点上，则还需要一些额外的工作，比如将这些特殊资源使用opaque-int-resource的方式对自定义资源进行量化，然后在PodSpec中进行请求；也可以使用标签的方式来标注这些安装有特别硬件的节点，然后在Pod中定义节点亲和性来实现这个目标。

3.基于污点的驱逐，以应对节点故障

前面提到的NoExecute这个Taint效果对节点上正在运行的Pod有以下影响。

◎　没有设置Toleration的Pod会被立刻驱逐。

◎　配置了对应Toleration的Pod，如果没有为tolerationSeconds赋值，则会一直留在这一节点中。

◎　配置了对应Toleration的Pod且指定了tolerationSeconds值，则会在指定时间后驱逐。

◎　把节点故障标记为Taint

当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括：

node.kubernetes.io/not-ready：节点未准备好。这相当于节点状态 Ready 的值为 "False"。

node.kubernetes.io/unreachable：节点控制器访问不到节点. 这相当于节点状态 Ready 的值为 "Unknown"。

node.kubernetes.io/out-of-disk：节点磁盘耗尽。

node.kubernetes.io/memory-pressure：节点存在内存压力。

node.kubernetes.io/disk-pressure：节点存在磁盘压力。

node.kubernetes.io/network-unavailable：节点网络不可用。

node.kubernetes.io/unschedulable: 节点不可调度。

node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 启动时指定了一个 "外部" 云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。

在节点被驱逐时，节点控制器或者 kubelet 会添加带有 NoExecute 效应的相关污点。 如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。

说明： 为了保证由于节点问题引起的 Pod 驱逐 速率限制行为正常， 系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下， 这样做可以避免 Pod 被大量驱逐。

例如，一个包含很多本地状态的应用可能需要在网络发生故障时，还能持续在节点上运行，期望网络能够快速恢复，从而避免被从这个节点上驱逐。

Pod的Toleration可以这样定义：

tolerations :

- key : "node.kubernetes.io/unreachable"

operator:"Exists"

effect : "NoExecute"

tolerationSeconds : 6000

说明：

如果没有为Pod指定node.kubernetes.io/not-ready的Toleration，那么Kubernetes会自动为Pod加入tolerationSeconds=300 的node.kubernetes.io/not-ready类型的Toleration。

同样，如果Pod没有定义node.kubernetes.io/unreachable的Toleration，那么系统会自动为其加入tolerationSeconds=300 的node.kubernetes.io/unreachable类型的Toleration。

这些系统自动设置的toleration在Node发现问题时，能够为Pod确保驱逐前再运行5min。这两个默认的Toleration由AdmissionController“DefaultTolerationSeconds”自动加入。

DaemonSet 中的 Pod 被创建时， 针对以下污点自动添加的 NoExecute 的容忍度将不会指定 tolerationSeconds：node.kubernetes.io/unreachable

node.kubernetes.io/not-ready

这保证了出现上述问题时 DaemonSet 中的 Pod 永远不会被驱逐。