Kubernetes Pod 报 unbound immediate PersistentVolumeClaims：先查 PVC 没有绑定的条件

StatefulSet 的 Pod 长时间 Pending，事件包含 pod has unbound immediate PersistentVolumeClaims，同时 PVC 也是 Pending。这时容器通常尚未获得所需存储，反复重启应用或修改数据库密码不会完成卷绑定。

本文针对普通 PVC 与静态 PV 的匹配检查，也说明没有动态供应器的 StorageClass。该报错没有指出唯一根因，应从实际 PVC 的事件和声明判断，不能看到 PV 比 PVC 大就缩小卷。

先找到 Pod 实际引用的声明

下面均为供读者使用的检查示例。team-app、mysql-0 和 data-mysql-0 需要换成实际名称：

kubectl describe pod mysql-0 -n team-app
kubectl get pvc -n team-app
kubectl describe pvc data-mysql-0 -n team-app
kubectl get pv

Pod 与 PVC 属于命名空间，PV 是集群范围的对象。StatefulSet 的 volumeClaimTemplates 通常会为实例生成声明；手写的 claimName 又可能指向另一张 PVC。先核对 Pod 的卷引用，避免只检查名字相近、实际没有被使用的声明。

PVC 已 Bound，但 Pod 仍待调度时，应重新看调度事件，例如卷节点限制或其他资源条件。不要继续沿“没有可匹配 PV”的假设处理。

容量够用只是匹配条件之一

静态 PV 的容量必须至少满足 PVC 请求，不要求数值完全相等。PVC 请求 3Gi、PV 声明 10Gi，单凭这两个数字不能判断不匹配；也不应为了它们相等修改真实存储容量。

继续对照以下字段及状态：

• storageClassName 是否符合预期；有类名和空字符串不是同一种声明。
• PV 提供的 accessModes 是否包含 PVC 请求的模式，volumeMode 是否相容。
• PVC 如有标签 selector，PV 的标签是否全部满足；如指定 volumeName，目标 PV 是否确实存在且适用。
• PV 是否已绑定到另一张声明。一个已被占用的 PV 不能仅因容量够大就再分给新 PVC。

先用这些可观察信息缩小原因，再补充适用的 PV 或修正尚未承载数据的声明。已有声明的字段并非都能随意修改；保留清单和数据备份，按集群支持的变更流程处理，不要默认删 PVC 重建。

no-provisioner 不会凭空创建一个卷

查看 PVC 使用的 StorageClass：

kubectl get storageclass
kubectl get storageclass local-storage -o yaml

local-storage 是示例名称。kubernetes.io/no-provisioner 表示该类没有动态供应器，需要管理员预先提供适合的静态 PV。只建一个 StorageClass，不会自动创建磁盘、目录或可绑定卷。

如果期望动态供应，应检查类对应的供应器、控制器运行状态和 PVC 的供应事件；如果使用本地卷，则还要正确声明卷所在节点。原生 local 卷需要节点亲和性，不能把单机目录误当成所有节点共享的存储。

本地等受节点约束的卷通常配合 WaitForFirstConsumer，让绑定考虑 Pod 的调度条件。该模式下，尚无使用者时 PVC 等待并不一定是故障。现有类的绑定模式等字段有变更限制，应设计新类与工作负载的迁移，不能盲目覆盖生产类。

保留数据，再处理生命周期

不要用删除 PV、PVC、清除 claimRef 或格式化目录作为通用修复。回收策略和存储实现决定删除后的影响，Delete 可能清理后端存储；Retain 也不等于可以把有数据的卷直接交给另一应用。

修正前记录对象、绑定关系、真实数据位置和回收策略，保留可恢复备份。仅配置调整的回退按原清单恢复；涉及重新供应或迁移数据时，按存储维护流程完成，不能依赖撤销命令自动恢复数据。

成功标准是实际被引用的 PVC 已绑定到预期 PV，Pod 能在允许的节点启动，挂载路径与数据符合预期。PVC 变成 Bound 后若应用仍报错，应分别检查挂载、文件权限与数据版本，不再把所有故障归为卷匹配。