Dynamic Volume Provisioning
Binding only works if a matching volume already exists, so what happens when none does? The claim names a StorageClass, the class names a provisioner, and the binding controller copies that name onto the claim for the provisioner to pick up. The provisioner calls CreateVolume on the driver to carve a real disk out of the backend, then writes a PersistentVolume for it that already carries the claimRef. The disk is built to order.
Play the animation 5 steps, animated, best on a wide screen
Dynamic Volume Provisioning, step by step
-
With static provisioning an administrator has to create the volume by hand before anyone can claim it. Here nobody did, so the binding controller finds no candidate to bind to. Under the default Immediate binding mode it turns to the class the claim names, and copies the provisioner that class names onto the claim as an annotation.
Play from step 1 -
The StorageClass names a provisioner and the parameters to build with. The external-provisioner sidecar watches for unbound claims whose volume.kubernetes.io/storage-provisioner annotation carries its own name, picks this one up, and reads both the size the claim asks for and the parameters its class carries.
Play from step 2 -
The provisioner calls CreateVolume on the driver, which asks the storage backend for a real disk of the requested size. The backend carves one out and hands back the identifier it can be addressed by later. This is the only step here that touches real hardware: getting the disk onto a Node comes later, once a Pod uses the claim.
Play from step 3 -
A disk on its own is invisible to Kubernetes. The provisioner writes a PersistentVolume object carrying the identifier it just got back, and that object is the cluster representation of the disk. Only now does the volume exist as something a claim can be paired with.
Play from step 4 -
The new volume was built for this one claim, so the provisioner already stamped it with a claimRef pointing back at the claim. The binding controller still runs its usual match, and that pre-bound volume wins outright. It marks the volume Bound first, then writes volumeName on the claim and turns the claim Bound. The volume was made to order.
Play from step 5