KubernetesLI · StorageClassesStorageClasses
Volume binding modes — Immediate vs WaitForFirstConsumer in depth
What you'll learn
- Explain the difference between Immediate and WaitForFirstConsumer
- Identify when each binding mode is appropriate
- Apply topology-aware provisioning for multi-AZ clusters
- Recognize the failure modes of misconfigured binding modes
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
The volume binding mode determines when the PV is created and bound to the PVC. The choice has direct implications for multi-AZ correctness. This lesson walks both modes in depth.
Immediate binding
volumeBindingMode: Immediate
The PV is created and bound at PVC submission time:
sequenceDiagram
participant U as User
participant API as API server
participant CSI as CSI provisioner
U->>API: submit PVC
API->>CSI: CreateVolume (in default AZ)
CSI-->>API: PV created
API-->>U: PVC Bound
Note over U,API: PV may be in a different AZ than the Pod
The PV is created in the default location (zone, region, or backend default). The PV may be in a location that the Pod cannot reach (e.g., different AZ with cloud-block storage).
WaitForFirstConsumer binding
volumeBindingMode: WaitForFirstConsumer
The PV is created when a Pod that consumes the PVC is scheduled:
sequenceDiagram
participant U as User
participant API as API server
participant S as Scheduler
participant CSI as CSI provisioner
U->>API: submit PVC
API-->>U: PVC Pending (no Pod scheduled)
U->>API: create Pod with PVC
API->>S: schedule Pod
S->>API: Pod scheduled to AZ-a
API->>CSI: CreateVolume in AZ-a
CSI-->>API: PV created in AZ-a
API-->>U: PVC Bound in AZ-a
The PV is created in the Pod’s location. The PV is guaranteed to be reachable from the Pod.
When to use each
| Scenario | Binding mode |
|---|---|
| Single-AZ cluster | Immediate or WaitForFirstConsumer |
| Multi-AZ cluster with cloud-block | WaitForFirstConsumer |
| Multi-AZ cluster with network filesystem (NFS, CephFS) | Either |
| Network filesystem with single server | Either |
| Pre-provisioned PVs | N/A (PV exists before PVC) |
| Static provisioning | N/A |
The default for new StorageClasses in production is
WaitForFirstConsumer. It is always safe; it is only
slightly slower than Immediate (the PV is created after
the Pod is scheduled, not before).
Topology-aware provisioning
Combined with allowedTopologies, WaitForFirstConsumer
ensures the PV is created in a specific topology:
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
- key: topology.kubernetes.io/zone
values: ["us-east-1a", "us-east-1b", "us-east-1c"]
- matchLabelExpressions:
- key: topology.kubernetes.io/region
values: ["us-east-1"]
The PV is created in a zone that matches the expression AND the Pod’s scheduled zone. The Pod’s node must have the topology label; the PV’s zone must match.
# Verify the node's topology labels
kubectl get nodes --show-labels | grep topology.kubernetes.io/zone
# node-1 ... topology.kubernetes.io/zone=us-east-1a
# node-2 ... topology.kubernetes.io/zone=us-east-1b
# node-3 ... topology.kubernetes.io/zone=us-east-1c
Failure modes
The failure modes of misconfigured binding modes:
Immediate in a multi-AZ cluster
The PV is created in an arbitrary AZ. Pods scheduled to a different AZ cannot mount the volume. The Pod is stuck in ContainerCreating.
WaitForFirstConsumer without allowedTopologies
The PV is created in the Pod’s AZ, but if the Pod’s AZ is not in the cluster’s AZs (e.g., the node is in a region that the storage backend does not support), the PV cannot be created. The PVC is Pending.
WaitForFirstConsumer with a slow provisioner
The PV is not created until the Pod is scheduled, which adds latency. If the provisioner is slow, the Pod’s container start is delayed.
The scheduler’s role
The scheduler is the bridge between the Pod and the PVC. With WaitForFirstConsumer:
- The Pod is created with the PVC reference.
- The scheduler sees the Pod; the Pod has unsatisfied volume claims.
- The scheduler reserves a volume claim reference in the PV; the PV is created in the Pod’s zone.
- The scheduler binds the Pod to a node.
- The PVC binds to the PV.
The scheduler’s volume binding logic is in
kube-scheduler’s VolumeBinding plugin.
Quiz
Knowledge check · 4 questions
Q1. A multi-AZ EKS cluster has a StorageClass with `volumeBindingMode: Immediate`. A PVC is submitted and binds. The Pod is scheduled to a different AZ. What happens?
Q2. WaitForFirstConsumer is always safe and slightly slower than Immediate.
Q3. Your team is migrating a cluster from Immediate binding to WaitForFirstConsumer. Walk through the migration steps.
Existing StorageClass uses Immediate. New requirement: multi-AZ correctness. The migration must not disrupt running workloads.
Q4. Explain why WaitForFirstConsumer is required for multi-AZ clusters with cloud-block storage and what the failure mode is without it.
Passing score: 75%. Answers are checked in this browser.
Production discipline
WaitForFirstConsumeris the production default. Always safe; only slightly slower than Immediate.Immediateis acceptable for single-AZ clusters or network filesystems. For multi-AZ cloud-block, it is a footgun.allowedTopologiesconstrains the topology. The PV is created in a zone that matches the Pod’s zone.- Verify the node’s topology labels. The labels must
match
allowedTopologiesfor the binding to succeed.