K8S 污点和容忍度（Taint，Toleration）

介绍

在 Kubernetes 中，污点（Taints）和容忍度（Tolerations）是用于节点调度的一种机制，它们允许你控制哪些 Pod 能够调度到哪些节点上。

污点（Taints）

污点是节点上的一种属性，它会阻止未经授权的 Pod 调度到该节点上。当你在节点上设置了一个污点时，只有那些具有匹配容忍度的 Pod 才能够在该节点上被调度。

作用方式：污点通过给节点添加标签的方式生效。
语法：污点由 key、value 和 effect 三个部分组成。
key：污点的名称。
value：污点的值。
effect：污点的影响，可以是 “NoSchedule”（默认）或 “PreferNoSchedule”。“NoSchedule” 表示将阻止未经容忍的 Pod 调度到该节点上，而 “PreferNoSchedule” 表示尽量不在该节点上调度未经容忍的 Pod，但不是绝对禁止。

创建污点

kubectl taint nodes node01 key1=value1:NoSchedule
1

查看污点

# 查看所有节点的是否有污点
[root@master01 ~]# kubectl describe node | grep -i taint
Taints:             <none>
Taints:             <none>
Taints:             <none>
Taints:             key1=value1:NoSchedule
Taints:             <none>
1
2
3
4
5
6
7

删除污点

kubectl taint nodes node1 key1=value1:NoSchedule-
1

容忍度（Tolerations）：

容忍度是 Pod 的一个属性，它允许 Pod 被调度到带有指定污点的节点上。如果 Pod 具有与节点上设置的污点匹配的容忍度，则它可以被调度到该节点上。

作用方式：通过在 Pod 的 YAML 配置中添加 tolerations 来指定。
语法：容忍度由 key、operator、value、effect 四个部分组成。
key：与节点上设置的污点的 key 匹配。
operator：用于指定匹配规则，常见的有 “Equal”、“Exists”、“Exists”。
value：与节点上设置的污点的 value 匹配。
effect：与节点上设置的污点的 effect 匹配。

添加容忍度

这是部分yaml文件内容，添加容忍度其实类似于添加标签。

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
1
2
3
4
5

具体应用

根据咱们上面添加的污点设置一下nginx Pod容忍度。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    value： "value1"
    operator: "Exists"
    effect: "NoSchedule"
    operator: "Equal"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

部署这个Pod以后将会调度到node01上面。

operator 字段解释：

• operator: “Equal” ： 当 operator 设置为 “Equal” 时，容忍度会精确匹配节点上设置的污点的键、值和效果。只有当节点上的污点的键、值和效果与容忍度配置中的完全匹配时，Pod 才能够被调度到该节点上。
• operator: “Exists” ： 当 operator 设置为 “Exists” 时，容忍度只关注节点上是否存在指定键的污点，而不关心污点的值和效果。只要节点上存在与容忍度配置中的键匹配的污点，无论其值和效果如何，Pod 都能够被调度到该节点上。
• operator: “Exists” ： 当 operator 设置为 “DoesNotExist” 时，容忍度只关注节点上是否不存在指定键的污点。只有当节点上不存在与容忍度配置中的键匹配的污点时，Pod 才能够被调度到该节点上。

effect 字段解释

• effect: “NoSchedule” ：除非具有匹配的容忍度规约，否则新的 Pod 不会被调度到带有污点的节点上。 当前正在节点上运行的 Pod 不会被驱逐。
• effect: “PreferNoSchedule” ：PreferNoSchedule 是“偏好”或“软性”的 NoSchedule。 控制平面将尝试避免将不能容忍污点的 Pod 调度到的节点上，但不能保证完全避免。
• effect: “NoExecute” ：如果 Pod 不能容忍这类污点，会马上被驱逐。
  如果 Pod 能够容忍这类污点，但是在容忍度定义中没有指定 tolerationSeconds， 则 Pod 继续运行，如果 Pod 能够容忍这类污点，而且指定了 tolerationSeconds， 则 Pod 还能在这个节点上继续运行这个指定的时间长度。 这段时间过去后，节点生命周期控制器从节点驱除这些 Pod。

举个例子：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600  # 容忍度持续时间为 3600 秒（1 小时），超过这个时间仍然会呗驱逐。
1
2
3
4
5
6
7
8
9
10
11
12
13
14

说明

• 可以给一个节点添加多个污点，也可以给一个 Pod 添加多个容忍度设置。 Kubernetes 处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历， 如果全部匹配则调度到该节点，只要有一个不匹配就不会调度到该节点。

基于污点的驱逐

• node.kubernetes.io/not-ready：节点未准备好。这相当于节点状况 Ready 的值为 “False”。
• node.kubernetes.io/unreachable：节点控制器访问不到节点. 这相当于节点状况 Ready 的值为 “Unknown”。
• node.kubernetes.io/memory-pressure：节点存在内存压力。
• node.kubernetes.io/disk-pressure：节点存在磁盘压力。
• node.kubernetes.io/pid-pressure：节点的 PID 压力。
• node.kubernetes.io/network-unavailable：节点网络不可用。
• node.kubernetes.io/unschedulable：节点不可调度。
• node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 启动时指定了一个“外部”云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。

通过污点和容忍度的组合，你可以精确地控制 Pod 在 Kubernetes 集群中的调度行为，确保特定类型的任务被分配到特定类型的节点上，从而更好地管理资源和提高系统的稳定性和可靠性。