关于Kubernetes异常容忍度的疑问：Pod调度至带污点节点的原因

问题1：为何Pod能调度到带有Runtime=true:NoSchedule污点的节点？ #

节点上的污点Runtime=true:NoSchedule属于NoSchedule类型的污点，结构为key=value:effect。

再看Pod的容忍度配置：

tolerations:
  - key: CriticalAddonsOnly
    operator: Exists
  - effect: NoExecute
    operator: Exists
  - effect: NoSchedule
    operator: Exists

其中第三条容忍度- effect: NoSchedule operator: Exists的作用是：匹配所有effect为NoSchedule的污点，无需考虑污点的key和value。

当operator设为Exists且未指定key时，Kubernetes会忽略污点的key和value，仅校验effect是否一致。节点上的Runtime=true:NoSchedule污点正好满足effect为NoSchedule的条件，因此Pod能容忍该污点，可被正常调度到该节点。

问题2：仅配置effect: NoSchedule operator: Exists的容忍度如何生效？ #

单独的这条容忍度配置：

- effect: NoSchedule
  operator: Exists

生效逻辑如下：

• 该容忍度会匹配所有effect为NoSchedule的节点污点，不管污点的key、value是什么。
• 换句话说，只要节点上的污点是NoSchedule类型，无论它是标记特殊硬件、运行时环境还是其他用途，这个Pod都能绕过该污点的调度限制，被部署到该节点上。

内容的提问来源于stack exchange，提问作者liam xu