Sanitation teams create new PersistentVolumeClaims that remain Pending while the CSI controller pod crash-loops. What does this indicate?
Select an answer to reveal the explanation.
Short Explanation
Dynamic volumes need the CSI controller's help to call the storage backend—like a permits desk that stamps new claims. If that desk's pod crash-loops, fresh PVCs sit Pending.
Full Explanation
Dynamic provisioning for PersistentVolumeClaims depends on healthy CSI controller components that call the storage backend and create PersistentVolumes. When sanitation teams create new PVCs that remain Pending while the CSI controller crash-loops, that indicates provisioning cannot complete—claims often stay unbound until the controller recovers. CSI controller crashes are not limited to ClusterIP Services and do affect volume provisioning; claiming they never touch volumes reverses the real impact. Pending PVCs do not always mean the kube-scheduler binary was deleted from every node; scheduling and provisioning are distinct, and the stem’s crash-looping CSI controller is the direct clue. CoreDNS outages do not uniquely freeze PVC binding whenever CSI is healthy; while DNS can matter for some external storage APIs, the given unhealthy CSI controller is the primary signal here. Exam caveat: Pending PVC can also mean no default StorageClass, selector mismatches, access-mode conflicts, or quota exhaustion—always read PVC Events. With a crash-looping CSI controller called out, start there. Operational check: Inspect CSI controller pods and logs, fix RBAC, credentials, or backend connectivity, watch PVC Events progress to Bound, then mount a test volume from a civic workload pod.