嘿，遇到PVC一直卡Pending确实头疼，咱们一步步来梳理排查方向，你可以跟着这些步骤逐一验证：

1. 先确认StorageClass的有效性 #

• 先看看你的StorageClass是否存在且状态正常：

  kubectl get storageclasses
  

• 重点检查PROVISIONER字段，这个必须是集群已经部署好的存储插件（比如kubernetes.io/nfs、local-path-provisioner这类），如果是自定义的provisioner，得确保它在集群里正常运行
• 另外留意VOLUMEBINDINGMODE，如果是WaitForFirstConsumer，那PVC会等到有Pod去绑定它的时候才会触发PV创建，这种情况属于正常逻辑，不是异常

2. 核对PV与PVC的绑定匹配条件 #

• 先列出所有PV，看看有没有符合PVC需求的可用资源：

  kubectl get pv
  

• 对比PVC和PV的关键参数，必须完全匹配：
  • storageClassName：名称要完全一致，K8s对大小写敏感，别因为大小写不一致导致匹配失败
  • 存储容量：PVC请求的resources.requests.storage不能超过PV的可用容量
  • accessModes：比如PVC要求ReadWriteMany，那PV也得支持这个模式，不能PV只支持ReadWriteOnce
• 如果是手动创建的静态PV，得确保它的状态是Available，要是已经被别的PVC绑定了（状态Bound），那肯定没法再绑定你的PVC

3. 深挖PVC Describe的关键信息 #

这部分是定位问题的核心，你可以从PVC的Describe输出里找线索：

• 重点看Events区域，这里会直接给出绑定失败的原因，比如：

  示例错误提示：Failed to provision volume with StorageClass "my-sc": provisioner "unknown-provisioner" not found
  或者：No persistent volumes available for this claim and no storage class is defined.

• 检查Status和Volume字段，如果Volume是空的，说明确实没找到合适的PV绑定
• 看看有没有WaitForFirstConsumer相关的提示，要是有，那就是前面说的等待Pod绑定的正常情况

4. 检查动态供给的Provisioner状态 #

如果你的StorageClass是动态创建PV的：

• 先看看对应的provisioner Pod是否在正常运行，大部分内置的provisioner都在kube-system命名空间：

  kubectl get pods -n kube-system
  

• 查看provisioner的日志，比如nfs-client-provisioner的日志：

  kubectl logs <provisioner-pod-name> -n kube-system
  

  日志里通常会有创建PV失败的具体原因，比如存储服务器连接失败、权限不足之类的

5. 排查其他潜在问题 #

• 资源配额限制：检查PVC所在的命名空间有没有设置存储配额，是不是请求的存储量超出了配额：

  kubectl get resourcequota -n <你的命名空间>
  

• 权限问题：比如provisioner没有权限去创建后端存储资源（比如云存储的API密钥不对，或者NFS服务器的挂载权限不足）
• 网络连通性：如果用的是远程存储（比如Ceph、云块存储），检查集群节点和存储服务器之间能不能正常通信

要是你能把以下信息贴出来，我可以更精准地帮你定位问题：

• kubectl get sc,pv,pvc -o yaml的输出（敏感信息可以打码）
• PVC Describe的完整输出（尤其是Events部分）

内容的提问来源于stack exchange，提问作者Sohail Anjum