Kubernetes Pod 一直 Pending — 未容忍 Taint

症状

错误“Kubernetes Pod 一直 Pending — 未容忍 Taint”指向一个明确的失效模式。下面依次给出症状、定位该原因的检查命令、根本原因、修复方案，以及证明修复有效的验证步骤。

可观察到的症状包括：

• Pod 持续 Pending 并提示 “has taints that pod does not tolerate”
• 所有节点都有 taint，没有 Pod 能调度
• 一个工作负载可调度，另一个不行

诊断

先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。

步骤 1

kubectl describe pod <pod> | grep -A 5 "Events"

FailedScheduling 事件会列出候选节点上的 taint 与缺失的容忍。

步骤 2

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

查看 taint 即可确定应添加哪个容忍。

常见诱因（按出现频率排序）：

• 目标节点带有 Pod 未容忍的 taint（如 dedicated=gpu:NoSchedule）
• nodeSelector 或亲和限制了不存在的节点
• 控制平面节点带 taint，而工作负载期望在其上运行

根因

taint 会排斥未声明匹配容忍的 Pod。对于 NoSchedule，调度器拒绝把不容忍的 Pod 放到带 taint 的节点；若无未打 taint 的合适节点，Pod 便一直 Pending。

修复

添加与节点 taint 匹配的容忍（效果要正确），或在不再需要时移除 taint，并让 nodeSelector 与亲和和既有节点标签一致。

注意：容忍 taint 并不保证被放到该节点；若需专用放置，还须用亲和规则选中它。

spec:
  tolerations:
    - key: dedicated
      operator: Equal
      value: gpu
      effect: NoSchedule
  affinity:
    nodeAffinity:   # also select the dedicated nodes
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: dedicated
                operator: In
                values: ["gpu"]

验证

确认 Pod 调度到节点并进入 Running；验证不再出现 FailedScheduling 事件。

修复后补充一条回归测试，复现原始症状，防止问题再次出现。

这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。