A volume binding mode is a StorageClass setting that controls when Kubernetes provisions and binds a PersistentVolume to a PersistentVolumeClaim. It determines whether the claim is handled immediately or after a pod begins using it. section 10.2.5 section 10.2.1
The supported modes differ in when the consumer’s location is known:
- Immediate provisions and binds the PersistentVolume as soon as the PersistentVolumeClaim is created. Because no consuming pod is known yet, this suits volumes accessible from any cluster node. section 10.2.5
- WaitForFirstConsumer delays provisioning and binding until the first pod referencing the claim is created. This lets scheduling account for storage that is limited to particular nodes. section 10.2.5 section 10.3.1
Table 10.4 Supported volume binding modes
|
Volume binding mode
|
Description
|
|---|---|
Immediate
|
The provision and binding of the PersistentVolume takes place immediately after the PersistentVolumeClaim is created. Because the consumer of the claim is unknown at this point, this mode is only applicable to volumes that can be accessed from any cluster node.
|
WaitForFirstConsumer
|
The PersistentVolume is provisioned and bound to the PersistentVolumeClaim when the first pod referencing this claim is created. Many StorageClasses now use this mode.
|
Compare Immediate and WaitForFirstConsumer when choosing a StorageClass for a claim. section 10.2.5
Binding a local volume after pod creation
A local StorageClass can use `WaitForFirstConsumer` with the `kubernetes.io/no-provisioner` provisioner. Creating a claim such as `quiz-data-local` leaves it unbound initially. Creating a pod that references the claim lets Kubernetes bind the claim to the local PersistentVolume and schedule the pod on the node that can access the volume. section 10.3.1 section 10.3.2
