PersistentVolumeClaim Pending: The claim has not been bound to a volume

A PVC in Pending has no volume behind it, so any pod using it cannot start. Either provisioning failed, no matching volume exists, or the claim is deliberately waiting for a pod to be scheduled first.

Applies to: All Kubernetes versions

What it means

A PersistentVolumeClaim is a request that must be satisfied before a pod can use it. It stays Pending until a PersistentVolume is bound to it. There are three distinct situations behind this, and one of them is not a problem at all: with volumeBindingMode: WaitForFirstConsumer, the claim waits on purpose until a pod using it is scheduled, so a Pending claim with no pod is expected. The other two are real: dynamic provisioning was attempted and failed, or provisioning is not configured and no pre-created volume matches the claim's requirements.

Most common causes

• The StorageClass uses WaitForFirstConsumer and no pod has been scheduled yet. This is normal.
• No StorageClass is named on the claim and the cluster has no default, so nothing provisions it.
• The named StorageClass does not exist — a typo, or a class present in another cluster.
• Dynamic provisioning failed, which appears as a ProvisioningFailed event on the claim.
• Static provisioning where no existing volume matches the requested size, access mode, or class.
• A namespace storage quota preventing the claim.
• The requested access mode is not supported by the backend — ReadWriteMany against block storage, for example.

How to diagnose it

1. Read the claim's events first: kubectl describe pvc CLAIM -n NAMESPACE. Everything relevant is there.
2. Check the StorageClass exists: kubectl get storageclass, and note which is marked default.
3. If the mode is WaitForFirstConsumer, check whether a pod referencing the claim exists and is schedulable — the pod is the thing that is stuck, not the claim.
4. For static provisioning, list available volumes and compare their capacity, access modes, and class: kubectl get pv.
5. Check namespace quotas: kubectl describe quota -n NAMESPACE.

How to fix it

1. Name an existing StorageClass, or mark one as default in the cluster.
2. If the claim is waiting for a consumer, fix whatever prevents the pod from being scheduled. The claim binds as soon as a node is chosen.
3. Resolve the provisioning failure reported in the events — usually credentials, quota, or capacity at the storage backend.
4. For static volumes, create one matching the claim's size, access mode, and class, or relax the claim.
5. Request an access mode the backend actually supports.

Notes

A claim requesting a size larger than the largest volume the backend can provision stays Pending with a provisioning error rather than binding to something smaller. Bindings are never partial, which is easy to forget when a request is a round number picked without checking the backend's limits.

Related

• ProvisioningFailed — Dynamic provisioning of a volume failed
• FailedMount — A volume could not be mounted into the pod

Sources

• Kubernetes documentation — Persistent Volumes
• Kubernetes documentation — Storage Classes
• Kubernetes documentation — Dynamic Volume Provisioning