PVC Pending: When Storage Never Binds

The app team opens a ticket: "New pods won't schedule."

kubectl get pod worker-0 -n data

NAME       READY   STATUS    RESTARTS   AGE
worker-0   0/1     Pending   0          12m

kubectl describe pod worker-0 -n data | grep -A2 Events

Warning  FailedScheduling  ...  pod has unbound immediate PersistentVolumeClaims

The scheduler is waiting on storage, not CPU.

Check the PVC

kubectl get pvc -n data

NAME          STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-worker   Pending                                      fast-ssd       12m

Pending PVC means no PersistentVolume is bound yet.

Trace the binding chain

1. StorageClass exists?

   kubectl get storageclass fast-ssd

   Typo in storageClassName → PVC waits forever.

2. Dynamic provisioner running?

   For cloud or CSI drivers, check the provisioner/controller pods in kube-system or the driver namespace. A dead provisioner leaves PVCs Pending.

3. Pre-provisioned PV available?

   If not using dynamic provisioning, you need a matching PV:

   kubectl get pv

   Match capacity, accessModes (RWO vs RWX), and storageClassName.

4. Multi-attach conflict

   RWO volumes attach to one node. A second Pod using the same claim on another node stays Pending — check volumeMode and access mode in exam and production scenarios.

Pod vs PVC order

volumeClaimTemplates on StatefulSets create PVCs automatically. Standalone Pods need the PVC Bound before the Pod can schedule (for volumeBindingMode: WaitForFirstConsumer, the order differs — the PVC may stay Pending until a Pod is scheduled that uses it).

Read the StorageClass volumeBindingMode — Immediate vs WaitForFirstConsumer changes what you inspect first.

Fix order

1. kubectl get pvc,pv,sc -n <ns>
2. kubectl describe pvc <name> → Events from the provisioner
3. Confirm StorageClass and access modes match the workload
4. Fix provisioner, create PV, or correct the claim spec
5. Re-check Pod Events — scheduling should proceed once Bound

Practice

Storage & Volumes on Decision Trainer covers PVC Pending, mount failures, and multi-attach — with runbook ordering so you check binding before restarting kubelet or deleting nodes.