Skip to content

PVC Stuck in Pending

Symptom

A PersistentVolumeClaim remains in Pending, often with no bound PV and no usable volume attached to the workload.

Possible Causes

  • The StorageClass uses WaitForFirstConsumer, but no pod is scheduled yet.
  • Zone or topology constraints cannot be satisfied for the requested storage class.
  • Quota, capacity, or storage-account constraints prevent provisioning.
  • The requested access mode or size does not match the storage family.

Diagnosis Steps

flowchart TD
    A[PVC is Pending] --> B[Describe PVC and inspect StorageClass]
    B --> C{WaitForFirstConsumer?}
    C -->|Yes| D[Check scheduling and zone placement of consuming pod]
    C -->|No| E[Check quota size and storage parameters]
    D --> F[Confirm topology and node availability]
    E --> F

  1. Inspect the PVC and its events.

    kubectl describe pvc "$PVC_NAME" \
    --namespace "$NAMESPACE"

  2. Inspect the referenced StorageClass.

    kubectl get storageclass "$STORAGE_CLASS_NAME" \
    --output yaml

  3. If the class uses WaitForFirstConsumer, inspect the consuming pod and its scheduling state.

    kubectl describe pod "$POD_NAME" \
    --namespace "$NAMESPACE"

  4. Verify node-zone labels and workload topology rules when using zonal disk classes.

    kubectl get nodes \
    --show-labels

Resolution

  • Create or schedule the consuming pod so a WaitForFirstConsumer PVC can bind.
  • Relax or correct zone constraints so the scheduler and storage class agree.
  • Adjust size, access mode, or storage class to match the requested storage family.
  • Resolve Azure quota or storage-account limitations before retrying.

Prevention

  • Use WaitForFirstConsumer for zonal disk classes unless you have a proven reason not to.
  • Standardize storage-class names and allowed sizes per workload tier.
  • Keep a zone-placement checklist for StatefulSets that use LRS disks.

See Also

Sources