Use WaitForFirstConsumer without bypassing the Kubernetes scheduler

Topology-aware volume binding needs the future Pod’s placement information.

Source facts

Kubernetes StorageClass Immediate mode can bind or provision a volume before the consuming Pod’s scheduling needs are known. WaitForFirstConsumer delays that work so placement constraints can inform volume selection. Kubernetes warns against using nodeName with this mode: bypassing the scheduler can leave the claim pending. A node selector can express a host preference without that bypass.

Source: Kubernetes documentation — Storage Classes.

Applicability

This applies to supported topology-constrained storage and StorageClass volume-binding modes. The provisioner’s capabilities still determine which modes are available.

DSE recommendation

DSE recommends checking the volume’s binding mode whenever a stateful Pod and its claim remain pending together. Review node affinity, selectors, capacity, and storage topology as one placement problem. Avoid assigning nodeName as a quick fix unless its consequences have been deliberately accepted. Document the intended failure-domain placement and use a policy that allows the scheduler and provisioner to coordinate. Keep backend eligibility information with the workload runbook so replacement nodes do not silently fall outside the storage’s reachable topology.

Verification

In a nonproduction namespace, inspect the sequence from claim creation through Pod scheduling and binding. Compare an approved selector-based Pod with a deliberately bypassed scheduler case. Confirm that the documented configuration resolves placement without forcing an inaccessible volume onto a node. Retain the StorageClass, effective selector and claim events as one record. Ask the storage owner to identify the provisioner capability used and the point at which the selected node’s topology influenced the binding decision.

Official reference

Kubernetes documentation — Storage Classes. Reviewed October 20, 2026.