kubectl get nodes --show-labels | grep disk kubectl describe pod api-9e8d7c6b5-7y2kq | grep -A6 Events kubectl label node node-2 disktype=ssd
三个 Pod 一直 Pending，describe 里写 0/6 nodes are available: 3 node(s) didn't match Pod's node affinity。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，nodeAffinity 要求 disktype=ssd，节点标签实际是 disk=ssd，key 对不上。requiredDuringScheduling 是硬约束，没有匹配节点就一直不调度。
「节点亲和性不匹配」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。同一份配置存在多处的，先确认改的是被加载的那一份。
新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。
处理上按这个顺序：用 --show-labels 看节点上真实的标签键值；把 requiredDuringScheduling 改成 preferred 先保证能调度；标签统一由节点池打 别手工在单台上加；改完看 scheduler 事件里是否还有 affinity 报错。
改完只确认一件事：Pending 的 Pod 在 10 秒内变成 Running 事件里不再出现 affinity 不匹配。