A transit PVC stays Pending. No matching static PV exists and no dynamic provisioner is available for its StorageClass. What is the most accurate diagnosis?
Select an answer to reveal the explanation.
Short Explanation
Pending on a PVC is the claim still waiting for a match. No static PV and no provisioner means that wait never ends.
Full Explanation
When a transit PVC stays Pending with no matching static PV and no dynamic provisioner available for its StorageClass, the accurate diagnosis is that the claim cannot bind because nothing satisfies it—neither a compatible PV nor a working provisioner for that class. Pending means the claim is still waiting for a match that never arrives until storage is fixed.
Pending does not always mean the kube-proxy DaemonSet crashed on every node. It does not always mean the PVC name collides with a Service of the same name. It does not always mean the cluster has no CoreDNS Pods. Those are different failure domains.
Exam caveat: also consider quota, WaitForFirstConsumer waiting on a Pod, and topology. Still, missing PV plus missing provisioner is the clean conceptual answer here.
Operational check: list PVs and StorageClasses, describe the PVC events, restore or correct the provisioner/class or create a matching static PV, and watch the transit claim Bind. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.