Skip to main content
RunBook Academy

KubernetesLI · StorageClassesStorageClasses

Volume binding modes — Immediate vs WaitForFirstConsumer in depth

Advanced⏱ ~16 minkubectl

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

Not yet marked complete on this device.

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

ScenarioBinding mode
Single-AZ clusterImmediate or WaitForFirstConsumer
Multi-AZ cluster with cloud-blockWaitForFirstConsumer
Multi-AZ cluster with network filesystem (NFS, CephFS)Either
Network filesystem with single serverEither
Pre-provisioned PVsN/A (PV exists before PVC)
Static provisioningN/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:

  1. The Pod is created with the PVC reference.
  2. The scheduler sees the Pod; the Pod has unsatisfied volume claims.
  3. The scheduler reserves a volume claim reference in the PV; the PV is created in the Pod’s zone.
  4. The scheduler binds the Pod to a node.
  5. The PVC binds to the PV.

The scheduler’s volume binding logic is in kube-scheduler’s VolumeBinding plugin.

Quiz

Knowledge check · 4 questions

  1. 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?

  2. Q2. WaitForFirstConsumer is always safe and slightly slower than Immediate.

  3. 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.

  4. 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

  • WaitForFirstConsumer is the production default. Always safe; only slightly slower than Immediate.
  • Immediate is acceptable for single-AZ clusters or network filesystems. For multi-AZ cloud-block, it is a footgun.
  • allowedTopologies constrains 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 allowedTopologies for the binding to succeed.