Kubernetes配置Pod容忍规则时为何需指定Effect字段？

基础配置方式 #

配置Kubernetes污点（Taints）与容忍度（Tolerations）机制时，给节点打污点的常用命令如下：

kubectl taint nodes node1 key1=value1:NoSchedule

配置完成后，没有对应容忍规则的Pod无法被调度到node1节点，只有匹配容忍规则的Pod才能调度到该节点。

常见疑问 #

不少使用者会提出问题：NoSchedule效果已经在节点侧的污点配置里定义了，为什么Pod侧的容忍规则还要单独指定effect字段？
能完全匹配上述污点的容忍规则配置示例如下：

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

effect不匹配的配置影响 #

如果出现如下配置组合：

1. 节点侧污点effect为NoSchedule，配置命令：

kubectl taint nodes node1 key1=value1:NoSchedule

2. Pod侧容忍规则的effect设置为NoExecute，配置如下：

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

该场景下容忍规则完全不生效，Pod依旧无法被调度到node1节点。容忍规则生效的前提是key、value、effect三个字段全部和节点上的污点匹配，三者缺一不可。

effect字段强制匹配的实际业务场景 #

官方对tolerations.effect字段的定义如下：

字符串类型，用于指定待匹配的污点效果，字段留空时表示匹配所有污点效果，指定取值时仅支持NoSchedule、PreferNoSchedule、NoExecute三个枚举值。

设计effect字段匹配逻辑的核心目的是给使用者提供细粒度的容忍范围控制，常见业务场景包括：

• 核心业务的故障容错控制：给业务专属节点打key=biz:NoSchedule污点保证只有对应业务Pod能调度时，业务Pod的容忍规则只需要匹配NoSchedule效果即可，不需要匹配NoExecute。这样当节点出现硬件故障、kubelet异常等问题，被自动打上node.kubernetes.io/unreachable:NoExecute这类污点时，Pod会被正常驱逐到其他健康节点，不会一直卡在故障节点影响服务可用性。
• 集群运维操作的粒度适配：运维做节点升级、排障时，会根据操作影响选择不同effect的污点：只是暂时不让新Pod调度就打NoSchedule，需要腾空节点就打NoExecute。不同业务可以根据自身特性配置容忍范围：比如离线批处理任务Pod可以容忍NoSchedule，暂时不调度也不影响核心服务，但不需要容忍NoExecute，避免运维腾空节点时批处理任务占着资源拖慢进度；而跑节点级监控、日志采集的DaemonSet Pod，需要同时容忍NoSchedule和NoExecute，保证运维操作期间节点的监控、日志采集不中断。
• 多优先级工作负载的分层调度：集群内通常同时存在三类不同强度的污点：软排他用PreferNoSchedule（尽量不调度非目标Pod）、硬排他用NoSchedule（完全禁止非目标Pod调度）、故障/资源压力驱逐用NoExecute（立刻驱逐不匹配的Pod）。不同优先级的Pod可以按需配置effect匹配规则：最高优先级的系统组件Pod可以留空effect字段，匹配所有效果的同key污点，保证极端情况下也能稳定运行；普通核心业务Pod只容忍PreferNoSchedule和NoSchedule，遇到节点故障、资源不足触发NoExecute时会被正常调度走；低优先级的测试、临时任务Pod不容忍任何硬排他污点，集群资源紧张时优先被清理。

内容的提问来源于stack exchange，提问作者Buggy B