A PersistentVolumeClaim that never binds means no StorageClass default, a provisioning gap, or a topology conflict. The PVC's events name the exact reason.
Your PVC doesn't specify a storageClassName and no default exists. Event: 'storageclass.storage.k8s.io "..." not found'.
The CSI driver is down, quota exceeded, or no zone matches the request (topology constraints).
Volume mode WaitForFirstConsumer deliberately doesn't bind until a pod references the PVC. No pod yet = Pending forever, by design.
kubectl describe pvc <claim> | tail -10
kubectl get storageclass
spec:
storageClassName: fast-ssd
accessModes: ["ReadWriteOnce"]
resources: { requests: { storage: 10Gi } }
kubectl -n kube-system get pods | grep -E 'csi|provision' && kubectl get quota -A
Bind failures don't self-heal silently — after fixing the class or driver, delete and recreate the claim. Changing storageClassName on a bound PVC is not allowed, and Kubernetes won't retry a failed bind for you.
No StorageClass matches, the provisioner isn't running, or WaitForFirstConsumer is waiting for a pod. kubectl describe pvc shows the exact event: 'no persistent volume available' vs 'waiting for first consumer' vs 'storageclass not found' each route differently.
With WaitForFirstConsumer (the sane default), yes: the volume is created only once a pod actually requests it, in the pod's zone. That's a feature — but it means a bare PVC with no consumer sits Pending by design.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.