An open-data team uses cloud disks that must land in the same zone as the scheduled Pod. Which StorageClass volumeBindingMode delays binding until a consumer Pod is scheduled?
Select an answer to reveal the explanation.
Short Explanation
Immediate binding is like assigning a locker before you know which gym floor the athlete uses—easy to pick the wrong building. WaitForFirstConsumer holds off until the Pod has a seating chart (node/zone), then provisions the disk where it can actually attach. That’s the topology-aware cloud-disk pattern.
Full Explanation
An open-data team using cloud disks that must land in the same zone as the scheduled Pod should set StorageClass volumeBindingMode: WaitForFirstConsumer. That mode delays binding and dynamic provisioning until a consumer Pod is scheduled, letting topology constraints influence volume placement. Immediate binding is like assigning a locker before you know which gym floor the athlete uses—easy to pick the wrong zone.
Immediate does not wait for the Pod’s nodeName before calling CSI; it binds as soon as the PVC is created. Recreate is not a Kubernetes volumeBindingMode that rebuilds PVs on kubelet restart. Manual is not a binding mode requiring kubectl bind before mounts.
Exam caveat: WaitForFirstConsumer works with Pod scheduling and CSI topology; if Pods never schedule, PVCs stay Pending by design. Immediate remains fine when topology is irrelevant.
Operational check: create a StorageClass with WaitForFirstConsumer, deploy a PVC plus a Pod with zone topology, confirm the PV appears only after scheduling, and verify the disk zone matches the Pod’s node. 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.