为什么已cordon的Kubernetes节点配置匹配Toleration仍无法调度Pod？

核心原因 #

你的猜测完全正确，kubectl cordon 操作确实会同步修改两个独立的节点调度控制属性，而非仅添加污点：

• 给节点添加key为node.kubernetes.io/unschedulable、效果为NoSchedule的内置污点
• 同时将节点spec.unschedulable字段设置为true，该字段是独立于污点机制、优先级最高的调度开关校验项

调度失败的逻辑 #

Kubernetes调度器的节点预选阶段会按优先级执行校验：

1. 第一步优先检查节点spec.unschedulable字段，如果为true，仅允许配置了node.kubernetes.io/unschedulable污点容忍的Pod进入后续校验，其他Pod会被直接过滤，不会走到后续的自定义污点匹配环节
2. 你仅为Pod配置了自定义污点env=production:NoSchedule的容忍，没有匹配内置的不可调度污点，因此在预选第一步就被拦截

uncordon后规则生效的原因 #

执行kubectl uncordon <node>时，会同步执行两个操作：

• 将节点spec.unschedulable字段重置为false，跳过最高优先级的不可调度校验
• 自动移除节点上的node.kubernetes.io/unschedulable:NoSchedule内置污点
  此时调度器会正常执行自定义污点匹配逻辑，你配置的容忍规则即可正常生效。

可选解决方案（若需要在cordon状态下放行指定Pod） #

给对应Pod额外添加内置不可调度污点的容忍即可：

tolerations:
# 新增内置不可调度污点容忍
- key: "node.kubernetes.io/unschedulable"
  effect: "NoSchedule"
  operator: "Exists"
# 原有自定义污点容忍保留
- key: "env"
  operator: "Equal"
  value: "production"
  effect: "NoSchedule"

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