本文永久链接: https://www.xtplayer.cn/kubernetes/tolerations-fuzzy-matching/

在 Kubernetes 中，Tolerations（容忍） 是 Pod 的一个属性，允许（但并不要求）Pod 被调度到具有相应 Taints（污点） 的节点上。

Toleration 的匹配规则不仅仅是“完全相等”，它提供了几种灵活的匹配方式，这也就是所说的 “模糊匹配”。核心的模糊匹配体现在对 operator 和 effect 字段的运用上。

Toleration 的核心结构

一个典型的 Toleration 定义如下：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
  tolerationSeconds: 3600 # 仅对 `NoExecute` 效果有效

关键字段：

  • key： 污点的键。
  • operator： 匹配操作符，这是实现“模糊匹配”的关键。值为 Equal 或 Exists。
  • value： 污点的值。当 operator 为 Equal 时，必须匹配；为 Exists 时，被忽略。
  • effect： 污点的效果。必须匹配，可以是 NoSchedule、PreferNoSchedule 或 NoExecute。也可以为空，表示匹配所有效果。

“模糊匹配”的几种场景

场景一：匹配特定键值对的污点（精确匹配）

这是最严格的一种，使用 operator: Equal。

  • 节点污点： key1=value1:NoSchedule

  • Pod 容忍：

    tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"

  • 解释：Pod 只会容忍键为 key1、值为 value1、效果为 NoSchedule 的污点。这是最精确的匹配。

场景二：匹配具有某个键的所有污点（忽略值）

这是第一种“模糊匹配”，使用 operator: Exists，并且不指定 value。

  • 节点污点： key1=value1:NoSchedule 或 key1=value2:NoSchedule 或 key1=anyvalue:NoSchedule

  • Pod 容忍：

    tolerations:
    - key: "key1"
      operator: "Exists" # 关键在这里
      effect: "NoSchedule"

  • 解释：只要节点上存在一个键为 key1、效果为 NoSchedule 的污点，无论它的值是什么（甚至是空值），Pod 都能容忍。这在你想容忍某一类（比如“专用GPU”）的所有节点时非常有用。

场景三：匹配所有具有特定效果的污点（忽略键和值）

这是更广泛的“模糊匹配”，不指定 key 并使用 operator: Exists。

  • 节点污点： anykey=anyvalue:NoSchedule

  • Pod 容忍：

    tolerations:
    - operator: "Exists" # 不指定 key
      effect: "NoSchedule"

  • 解释：Pod 会容忍节点上所有效果为 NoSchedule 的污点，无论它们的 key 和 value 是什么。这非常强大，但也非常危险，因为它让 Pod 几乎可以调度到任何节点。

场景四：匹配所有污点（忽略键、值和效果）

这是最极端的“模糊匹配”，容忍一切。

  • 节点污点： 任意污点。

  • Pod 容忍：

    tolerations:
    - operator: "Exists" # 不指定 key 和 effect

  • 解释：这个 Pod 会容忍任何污点。它可以被调度到集群中的任何节点上，无论该节点有什么污点。 这通常只应由系统级 Pod（如 kube-proxy、calico-node 等）使用。

场景五：匹配特定效果的所有污点（另一种形式）

通过将 effect 字段留空来实现。

  • 节点污点： key1=value1:NoSchedule 或 key2=value2:PreferNoSchedule

  • Pod 容忍：

    tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "" # 效果为空

  • 解释：这个容忍会匹配键为 key1、值为 value1，且效果为任意（NoSchedule, PreferNoSchedule, NoExecute）的污点。

特殊情况：tolerationSeconds

这个字段只对 effect: NoExecute 的污点有效，它实现了一种“延迟驱逐”的模糊匹配。

  • 节点污点： key1=value1:NoExecute

  • Pod 容忍：

    tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoExecute"
      tolerationSeconds: 60 # 关键在这里

  • 解释：当节点被加上这个 NoExecute 污点时，通常 Pod 会立即被驱逐。但有了这个配置，Pod 会“容忍”这个污点 60 秒。60秒后，如果污点仍然存在，Pod 才会被驱逐。这给了 Pod 一个“宽限期”，用于完成正在处理的任务或等待节点恢复。

总结与类比

你可以把 Tolerations 的匹配规则想象成一个逻辑判断：

operator key 指定 effect 指定 匹配条件
Equal 是 是 精确匹配：节点的 key、value、effect 必须完全相等。
Exists 是 是 键匹配：节点存在一个 key 和 effect 都相等的污点，不关心 value。
Exists 否 是 效果匹配：节点存在任何一个 effect 相等的污点，不关心 key 和 value。
Exists 否 否 全匹配：节点存在任何一个污点（无论 key, value, effect）。

最佳实践建议：

  1. 遵循最小权限原则：尽量使用最精确的匹配（operator: Equal）。
  2. **谨慎使用 operator: Exists**：特别是不要轻易使用不指定 key 的 Exists，这会让你的 Pod 获得过高的调度权限。
  3. **为关键工作负载使用 tolerationSeconds**：对于需要优雅终止的应用程序，配置 tolerationSeconds 可以避免服务中断。

通过灵活组合这些字段，你可以非常精细地控制 Pod 对于不同节点污点的“容忍”策略，从而实现复杂的节点调度需求。