17、Kubernetes核心技术 - 污点（Taints）和污点容忍（Tolerations）

上一篇文章介绍了节点亲和性，它主要实现的是将Pod强制或者尽可能调度到满足某些条件的node节点上【通过在Pod上添加属性，来确定Pod是否要调度到指定的节点上，k8s中的污点，它的行为刚好与节点亲和性相反，污点可以将节点和 Pod 达到互斥的效果，让Pod不被调度到存在污点的那些节点上【在Node节点上添加污点属性（Taints），来避免Pod被分配到不合适的节点上】；k8s中的污点容忍，则可以

每天都要进步一点点

1622人浏览 · 2024-01-05 14:49:26

每天都要进步一点点 · 2024-01-05 14:49:26 发布

一、概述

上一篇文章介绍了节点亲和性，它主要实现的是将Pod强制或者尽可能调度到满足某些条件的node节点上【通过在Pod上添加属性，来确定Pod是否要调度到指定的节点上】，k8s中的污点，它的行为刚好与节点亲和性相反，污点可以将节点和 Pod 达到互斥的效果，让Pod不被调度到存在污点的那些节点上【在Node节点上添加污点属性（Taints），来避免Pod被分配到不合适的节点上】；k8s中的污点容忍，则可以让 Pod 调度到带有污点的节点上。

taints（污点）

污点是定义在节点上的键值型属性数据，用于让节点拒绝将Pod 调度运行于其上，除非 Pod 有接纳节点污点的容忍度；

tolerations （污点容忍）

污点容忍是定义在 Pod 上的键值型属性数据，用于配置可容忍的污点，且调度器将 Pod 调度至其能容忍该节点污点的节点上或没有污点的节点上；

在k8s中，我们可以给节点添加一些污点，以便在该节点上不能调度任何 Pod，除非Pod明确定义了Tolerations，Tolerations 应用于 Pod，并允许（但不要求）Pod 调度到具有匹配污点的节点上。

可以使用命令 kubectl taint 给节点增加一个污点。比如：

kubectl taint node <node_name> key=value[effect]   

示例：
# 给节点 master 增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到这个节点。
kubectl taint node master key1=value1:NoSchedule       # 设置value值

effect可选值有三个：

NoSchedule：表示 Pod 将不会被调度到具有该污点的节点上，注意，已经正在运行中的Pod不受影响；
PreferNoSchedule：表示 Pod 将尽量避免调度到具有该污点的节点上，注意，已经正在运行中的Pod不受影响；
NoExecute：表示 Pod 将不会被调度到具有该污点的节点上，同时将节点上已经存在的 Pod 进行驱逐，注意，已经正在运行中的Pod也会受影响，因节点污点变动或Pod容忍度变动而不再满足匹配规则时，Pod对象将被驱逐；

可以对单个节点应用多个污点，对单个 Pod 应用多个容忍度。

二、污点和污点容忍示例

2.1、NoSchedule

NoSchedule表示 Pod 将不会被调度到具有该污点的节点上，注意，已经正在运行中的Pod不受影响。

假设当前k8s集群有两个node节点，node01和controlplane。我们先给node01节点添加一个NoSchedule类型的污点。

NoSchedule：表示 Pod 将不会被调度到具有该污点的节点上

#给节点添加污点
$ kubectl taint nodes node01 a=b:NoSchedule
node/node01 tainted

#查看某个节点的污点
$ kubectl describe node node01 | grep Taints
Taints:             a=b:NoSchedule

$ kubectl describe node controlplane | grep Taints
Taints:             <none>

然后我们创建一个三个副本的nginx的Pod：

vim taint-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx

创建三个副本的Pod：

$ kubectl apply -f taint-demo.yaml 
deployment.apps/nginx created

$ kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
nginx-748c667d99-5t842   1/1     Running   0          13s   192.168.0.8   controlplane   <none>           <none>
nginx-748c667d99-dptjw   1/1     Running   0          13s   192.168.0.6   controlplane   <none>           <none>
nginx-748c667d99-gvt5s   1/1     Running   0          13s   192.168.0.7   controlplane   <none>           <none>

我们看到，当前三个Pod都被调度到了controlplane这个节点，因为我们给node01节点设置了一个【a=b:NoSchedule】的污点，并且我们的Pod也没有配置污点容忍，所以Pod不能被调度到node01节点。

如果说我们希望Pod能调度到node01上，我们可以给Pod添加污点容忍，需要修改一下Pod的资源清单，添加tolerations污点容忍的配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
      tolerations:  # 污点容忍
        - key: "a"
          operator: "Equal"		# operator的默认值为Equal。（如果键相同且值相同，则容忍匹配污点）
          value: "b"
          effect: "NoSchedule"

如上配置表示Pod能够容忍节点中存在【a=b:NoSchedule】这个污点，说明Pod有资格被调度到存在这个污点的node上，但是，这并不能保证这个 Pod 一定被调度到该节点，因为我们没有指定任何node affinity或者nodeSelector。修改完成后重新应用Pod 清单文件：

$ vim taint-demo.yaml 
$ kubectl apply -f taint-demo.yaml 
deployment.apps/nginx configured

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
nginx-6bfd64d99c-4g9v9   1/1     Running   0          6s    192.168.0.9   controlplane   <none>           <none>
nginx-6bfd64d99c-lf8qv   1/1     Running   0          12s   192.168.1.3   node01         <none>           <none>
nginx-6bfd64d99c-ttscz   1/1     Running   0          4s    192.168.1.4   node01         <none>           <none>

我们看到，当给node01添加了污点容忍后，Pod也能够正常被调度到node01上了。

若要移除上述命令所添加的污点，可以执行：

#删除污点  kubectl taint node <node名称> key:[effect]-
$ kubectl taint nodes node01 a=b:NoSchedule- 
node/node01 untainted

$ kubectl describe node node01 | grep Taints
Taints:             <none>

2.2、NoExecute

NoExecute表示 Pod 将不会被调度到具有该污点的节点上，同时将节点上已经存在的 Pod 进行驱逐。

vim noexecute-taint-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx

$ kubectl apply -f noexecute-taint-demo.yaml 
deployment.apps/nginx created

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
nginx-748c667d99-2s88m   1/1     Running   0          9s    192.168.1.4   node01         <none>           <none>
nginx-748c667d99-lgndm   1/1     Running   0          9s    192.168.1.3   node01         <none>           <none>
nginx-748c667d99-tj4tc   1/1     Running   0          9s    192.168.0.6   controlplane   <none>           <none>

$ kubectl describe node node01 | grep Taints
Taints:             <none>
$ kubectl describe node controlplane | grep Taints
Taints:             <none>

可以看到，Pod被分别调度到两个节点上。接下来，我们给node01节点添加一个NoExecute类型的污点：

$ kubectl taint nodes node01 c=d:NoExecute
node/node01 tainted

$ kubectl describe node node01 | grep Taints
Taints:             c=d:NoExecute

然后我们再查看Pod详情：

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
nginx-748c667d99-tj4tc   1/1     Running   0          2m58s   192.168.0.6   controlplane   <none>           <none>
nginx-748c667d99-tt5db   1/1     Running   0          34s     192.168.0.7   controlplane   <none>           <none>
nginx-748c667d99-v687w   1/1     Running   0          34s     192.168.0.8   controlplane   <none>           <none>

可以看到，之前调度到node01的两个Pod，已经被驱逐了，然后重新被调度到controlplane节点上。

实际上任何不容忍NoExecute污点的Pod都将被立即驱逐，而能够容忍污点的Pod 将永远不会被驱逐。但是可以指定一个可选tolerationSeconds字段，该字段指示在添加污点后Pod 将保持绑定到节点的时间。例如：

tolerations:
- key: "c"
  operator: "Equal"
  value: "d"
  effect: "NoExecute"
  tolerationSeconds: 3600  # 表示当 Pod 被驱逐时，还可以在节点上继续运行的时间（仅可以和NoExecute配合使用）

如果这个Pod 正在运行并且有一个匹配的污点被添加到该节点，那么该Pod将保持绑定到该节点 3600 秒，然后被驱逐。如果在该时间之前移除了污点，则Pod不会被驱逐。

三、污点和污点容忍应用场景

1、专用节点：当想将一组节点专用于专有工作负载或特定用户时，您可以向这些节点添加一个污点，然后向它们的Pod 添加相应的容忍度。
2、具有特殊硬件的节点：对于具有专用硬件的节点，我们只希望具有这些要求的Pod 在这些节点上运行。污染将帮助我们并为使用特殊硬件的Pod 添加相应的容忍度。
3、基于污点的驱逐：当节点存在问题时，每个Pod可配置的驱逐行为。

四、k8s内置的一些污点

Kubernetes自1.6版本起支持使用污点自动标识问题节点，它通过节点控制器在特定条件下自动为节点添加污点信息实现。目前，内建使用的此类污点包含如下几个。

node.kubernetes.io/not-ready：节点进入NotReady状态时被自动添加的污点；

node.alpha.kubernetes.io/unreachable：节点进入NotReachable状态时被自动添加的污点；

node.kubernetes.io/out-of-disk：节点进入OutOfDisk状态时被自动添加的污点；

node.kubernetes.io/memory-pressure：节点内存资源面临压力；
node.kubernetes.io/disk-pressure：节点磁盘资源面临压力；

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

Kubernetes的核心组件通常都要容忍此类的污点，以确保其相应的DaemonSet控制器能够无视此类污点，便于节点上部署相应的关键性Pod对象，例如kube-proxy或kube- flannel等。

我们可以通过kubectl describe pod xx查看污点容忍信息，例如下面是kube-proxy的一些污点容忍配置：

Tolerations:                 op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/network-unavailable:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists
                             node.kubernetes.io/pid-pressure:NoSchedule op=Exists
                             node.kubernetes.io/unreachable:NoExecute op=Exists
                             node.kubernetes.io/unschedulable:NoSchedule op=Exists

参考：污点和容忍度 | Kubernetes

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub