EKS 1.24中污点与容忍未按预期生效的原因咨询

以下是导致无对应容忍度的Pod被调度到带有dedicated:druid:NoSchedule污点节点组的常见原因：

• 污点未成功应用到节点
  节点组配置的污点可能没有实际同步到groupB的节点上。可以通过执行kubectl describe node <groupB-node-name>查看节点的Taints字段，确认污点是否存在且配置正确（key、value、effect需完全匹配）。

• Pod包含非预期的匹配容忍度
  你认为Pod没有对应容忍度，但可能存在以下匹配情况：

  • Pod的容忍度使用了operator: Exists，例如：

    tolerations:
    - key: "dedicated"
      operator: "Exists"
      effect: "NoSchedule"
    

    这种配置会匹配所有key为dedicated的污点，不受value限制。
  • 容忍度未指定effect字段，此时默认会匹配所有effect类型（包括NoSchedule），只要key和value匹配就会生效。

• Pod通过nodeName强制指定节点
  如果Pod配置中直接设置了nodeName字段指定groupB的某个节点，Kubernetes会跳过调度器的污点检查逻辑，直接将Pod调度到该节点上。

• 调度器配置异常
  若集群使用了自定义调度器，或者默认调度器的配置被修改（比如禁用了污点容忍检查逻辑），可能导致调度规则不生效。可以检查集群是否使用非默认调度器，或确认默认调度器的配置状态。

• 节点污点被意外移除
  后续的节点组更新、运维操作可能意外移除了groupB节点上的污点。需重新检查节点的Taints字段，确认污点是否仍存在。

• 系统Pod的特殊规则
  部分系统Pod（如kube-proxy、calico-node等）默认带有容忍常见污点的配置，可能会被调度到带有该污点的节点上。如果是这类Pod属于正常现象；若为业务Pod则需排查上述其他原因。

内容的提问来源于stack exchange，提问作者Kaojun Song