Pod 指定 nodeName 后，WaitForFirstConsumer 的 PVC 一直 Pending
Pod 已指定节点，PVC 仍等 first consumer？核对 nodeName 与延迟绑定，改用调度器识别的节点约束，保留卷、数据和拓扑条件。
Pod 已经指定了节点，PVC 却仍停在 Pending，事件反复显示 waiting for first consumer to be created before binding。如果实际使用的 StorageClass 是 WaitForFirstConsumer，同时创建 Pod 的清单显式配置了 spec.nodeName，先检查这两个设置的组合。
nodeName 直接指定节点，会绕过调度器。延迟绑定需要调度过程协调 Pod 的放置与卷的节点条件；声明了一个 Pod，并不代表这一步已经完成。只要保留这个组合，反复创建相同配置的 Pod 通常仍会等待。
把 Pod、PVC 和 StorageClass 对上
以下是只读检查示例，team-app、sample、myclaim、local-path 都应换成实际名称：
kubectl get pod sample -n team-app -o yaml
kubectl describe pvc myclaim -n team-app
kubectl get storageclass local-path -o yaml
kubectl get nodes -L kubernetes.io/hostname
先从 Pod 的 volumes[].persistentVolumeClaim.claimName 找到它真正引用的 PVC，再核对 PVC 的 storageClassName。还要查看原始独立 Pod 清单，或其所属 Deployment、StatefulSet 等控制器的 Pod 模板，确认创建前已经显式指定 nodeName。正常调度完成后，调度器也会把节点写入现有 Pod 的这个字段；单看当前 Pod 的 YAML，不能证明它绕过了调度器。
只有对应类的 volumeBindingMode 确实为 WaitForFirstConsumer，且原始清单或 Pod 模板显式指定 nodeName，才符合本文的调度绕过路径。
还没有任何 Pod 使用 PVC 时，延迟绑定本来就可以保持等待。PVC 已经 Bound 后的挂载失败、供应器报错或调度资源不足，也要按各自事件处理，不能都归因于 nodeName。静态卷的容量、访问模式和类名匹配问题，可继续看 PVC 与 PV 的匹配检查。
保留节点约束，让调度器参与
需要把工作负载放在某个节点时，通常可以在其 Pod 模板中移除 nodeName，改用调度器识别的节点选择条件。下面只是模板片段，应合并进现有工作负载，保留原来的容器、卷、资源和其他调度设置：
spec:
template:
spec:
nodeSelector:
kubernetes.io/hostname: kube-01
这是 Deployment、StatefulSet 等带有 spec.template 的工作负载所用位置。若管理的是独立 Pod，nodeSelector 位于 Pod 自己的 spec 下。原有 nodeName 要在相应层级移除；仅增加选择器而保留它，仍没有恢复正常调度。
kube-01 必须是目标节点实际的 kubernetes.io/hostname 标签值，不要默认它等于节点对象名称。选择器也不会绕过污点、资源不足、卷的节点亲和性或存储拓扑限制。配置改完后若出现新的调度事件，沿新事件继续检查。
变更前保存工作负载和存储声明，确认真实数据位置、备份及允许中断的范围，再按该工作负载的更新流程生成新 Pod。不能指望直接编辑现有 Pod 的 nodeName 就完成迁移。StatefulSet 有自己的更新顺序；独立 Pod 重建则需要先核对旧实例、挂载和写入者状态。整个过程保留 PV、PVC 和后端数据。
不建议手工填写 PVC 的 volume.kubernetes.io/selected-node 来替代调度器协调，也不要为了消除等待就把生产 StorageClass 改成 Immediate。受节点约束的卷可能因此提前绑定到不适合工作负载的位置；现有类的字段也有变更限制。
看新 Pod 的绑定和挂载结果
更新后检查新 Pod 的节点及事件、PVC 绑定到的 PV、实际挂载路径与数据。成功应体现为调度器完成放置，声明绑定到符合拓扑的卷，应用在预期节点启动并能正确使用数据。
若去掉 nodeName 后仍等待，保留这次的新事件，检查供应器是否运行、该驱动是否支持延迟绑定，以及资源、污点和卷节点条件是否有可同时满足的节点。恢复旧清单可以撤销配置调整，但重新放回 nodeName 也可能恢复原来的等待；删除存储声明不属于这个问题的通用回退办法。