Pod 因节点 taint 未被正确去除且 toleration 不匹配而 Pending；需用 kubectl describe node 检查残留 taint，确认 Pod tolerations 完整覆盖 key、value 和 effect，并注意 K3s 默认 taint 为 node-role.kubernetes.io/master:NoSchedule。
当 K3s 节点上的 taint 没被正确去除，Pod 就可能因不满足 toleration 条件而始终处于 Pending 状态——这不是调度器“卡住”，而是明确拒绝调度。
确认节点是否仍有残留 taint
运行 kubectl describe node ，在输出末尾的 Taints 字段查看。即使你执行过 kubectl taint nodes ……-，也可能因拼写错误、key-value 不匹配或未指定 effect 导致删除失败。例如：
- 原 taint 是
node-role.kubernetes.io/control-plane:NoSchedule，但误删成kubectl taint nodes xxx node-role.kubernetes.io/control-plane-（缺 effect）→ 实际未生效 - K3s 默认给 control-plane 节点加的 taint 是
node-role.kubernetes.io/master:NoSchedule（注意是master，不是control-plane），旧版本 K3s 尤其常见
检查 Pod 是否声明了对应 toleration
不是所有 Pod 都能容忍任意 taint。查看 Pod YAML 中的 tolerations 字段，确认它显式覆盖了节点当前的 taint。常见遗漏包括：
- 只写了
key和operator，但没写effect，导致无法匹配NoSchedule或NoExecute - 使用了
operator: Exists却漏掉effect，而节点 taint 带 effect → 匹配失败 - Deployment/StatefulSet 模板里没加 toleration，仅在单独创建的 Pod 里加了 → 扩容出来的副本仍失败
留意 K3s 自动添加的 taint 行为
K3s 在启动时会根据角色自动打 taint：
-
--disable-agent启动的 server 节点默认带node-role.kubernetes.io/master:NoSchedule - agent 节点不会自动加 taint，但若手动用
k3s agent --node-taint启动，taint 会持久化在 systemd service 文件中，重启后依然存在 - 修改
/etc/systemd/system/k3s-agent.service后，必须运行systemctl daemon-reload && systemctl restart k3s-agent才生效
快速验证与修复步骤
按顺序执行以下命令，逐层排除：
- kubectl get nodes -o wide → 看 STATUS 是否 Ready，NotReady 节点上的 taint 通常无效或冲突
- kubectl describe node
| grep Taints → 精确看到当前 taint 列表 - kubectl taint nodes
key1=value1:NoSchedule- → 明确指定 key、value 和 effect 删除（value 为空则省略=value1） - kubectl get pod
-o yaml | yq ‘.spec.tolerations’ （或用kubectl explain pod.spec.tolerations）→ 核对 toleration 结构是否完整
