WaitForFirstConsumer is a volume-binding policy that delays PersistentVolumeClaim binding and provisioning until a pod using the claim is created. This lets scheduling account for where the volume can be accessed, which is especially important for node-local storage. section 10.3.1
A typical local-volume lifecycle is:
- Create a PersistentVolumeClaim using that StorageClass; the claim remains unbound because no consuming pod exists yet. section 10.3.2
- Create a pod that references the claim. Kubernetes then binds the claim, schedules the pod on an eligible node, and mounts the volume. section 10.3.2
Binding a local disk
A local StorageClass uses kubernetes.io/no-provisioner and WaitForFirstConsumer. A pre-provisioned local PersistentVolume exposes /tmp/my-disk and restricts access with node affinity. A claim requesting 1Gi stays pending until the quiz-local pod uses it; then it becomes Bound to local-disk-on-my-node. section 10.3.1 section 10.3.2
Listing 10.14 Creating a PersistentVolumeClaim from a VolumeSnapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quiz-data-from-snapshot
spec:
resources:
requests:
storage: 1Gi
accessModes:
- ReadWriteOncePod
dataSourceRef: #1
apiGroup: snapshot.storage.k8s.io #1
kind: VolumeSnapshot #1
name: quiz-data-1 #1
A claim restored from a VolumeSnapshot may also require a pod to begin restoration when the default StorageClass uses this policy. section 10.4.3
