Provision the disk in the zone the scheduler chose, and know how many nodes may mount it.

Block disks are zonal and usually attach to one node at a time. Two settings avoid most stuck-Pod incidents.

WaitForFirstConsumer is the modern default

Provisioning waits for a Pod so the disk is created where the scheduler already placed it.

Classic mistake

Scaling a Deployment that mounts one RWO claim across nodes: extra Pods stay Pending. Use a StatefulSet (one PVC per replica) or an RWX class.

kind: StorageClass
provisioner: pd.csi.storage.gke.io   # GKE
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

Zones and access modes decide whether a volume can attach

Cloud block storage is zonal: a disk created in one zone cannot be attached to a VM in another. With volumeBindingMode Immediate, the disk is provisioned as soon as the claim is created, before the scheduler has decided where the Pod will run. If the scheduler then picks a node in a different zone, the Pod is stuck Pending forever. WaitForFirstConsumer delays provisioning until a Pod uses the claim, so the disk is created in the zone the scheduler already chose. It is the correct default for zonal storage.

Access modes describe how many nodes may mount a volume at once. ReadWriteOnce (RWO) allows read-write by a single node, which is what most block storage supports (multiple Pods on that same node can share it). ReadOnlyMany (ROX) allows many nodes to read. ReadWriteMany (RWX) allows many nodes to read and write and requires a shared filesystem such as NFS, Google Filestore or Amazon EFS.

This explains a very common production failure: scaling a Deployment that uses a single RWO claim. The extra replicas land on other nodes and cannot attach the disk, so they stay Pending. For per-replica data use a StatefulSet with volumeClaimTemplates; for shared files choose an RWX class.

Connect this with Module 4: if you spread replicas across zones with topology spread constraints, each StatefulSet replica's disk will be created in its own zone. When a zone fails, that replica cannot simply move to another zone with its disk, so data-layer replication across zones is still your responsibility.