Why is a Pod with a PVC stuck Pending?

WHAT THIS TESTS Whether you can methodically diagnose why storage will not bind and read Kubernetes events instead of guessing.

A GOOD ANSWER COVERS A Pod stays Pending when it cannot be scheduled, and a frequent cause is an unbound PersistentVolumeClaim. Common reasons: the referenced StorageClass does not exist or is misnamed, so no provisioner runs; in a static setup, no existing PV matches the claim's requested capacity or access mode; the requested access mode like RWX is unsupported by the backend; the dynamic provisioner is failing, perhaps due to cloud quota, IAM permissions, or capacity in the target zone; or the StorageClass uses WaitForFirstConsumer, so the PVC intentionally stays Pending until a node is selected, which itself may be blocked. Topology mismatches, where the only available volume is in a zone with no schedulable node, also cause this. To diagnose, start with kubectl describe pod to see scheduling events and which condition fails, then kubectl describe pvc to read its Events, which usually state the exact reason such as no persistent volumes available or provisioning failed. Cross-check with kubectl get pvc, kubectl get pv, kubectl get storageclass, and inspect the provisioner or CSI controller logs.

COMMON WRONG ANSWERS Restarting or recreating the Pod without reading events. Assuming it is always a capacity problem. Ignoring access-mode or zone mismatches. Forgetting to check whether the StorageClass even exists.

LIKELY FOLLOW-UPS How does WaitForFirstConsumer change the symptom? How would a zone mismatch surface? Where are CSI provisioner logs? How do you fix a missing default StorageClass?

ONE CONCRETE EXAMPLE kubectl describe pvc data-app-0 shows an event provisioning failed: no storage class found; kubectl get storageclass reveals the manifest referenced standard but the cluster's default is gp2, so correcting the storageClassName lets the provisioner bind the volume and the Pod schedules.