Reserving a PersistentVolume
How do you hand a retained disk full of data to a new claim, and make sure no other claim grabs it first? An administrator points the claimRef of the Released PV at the new claim by name and namespace, with no UID, so the PV turns Available for that claim alone and the binder skips it for every other claim. The claim names the PV in volumeName with storageClassName set to an empty string and the binder pairs them, while volumeName alone reserves nothing.
Play the animation 4 steps, animated, best on a wide screen
Reserving a PersistentVolume, step by step
-
PV pv-data is Released: its claimRef still names the deleted claim app/data, UID included, so no claim can bind it. An administrator patches the claimRef to name app/restore, with no UID. A claimRef without a UID is a reservation, so the PV controller writes Available, for that one claim, which does not even exist yet.
Play from step 1 -
PVC app/scratch arrives asking for 10Gi with an empty storageClassName, a fit for pv-data in every other way. The binder skips any volume whose claimRef names another claim, so pv-data is not even a candidate. The rival gets a FailedBinding event and stays Pending, while the reserved volume keeps waiting for app/restore.
Play from step 2 -
Now app/restore is created with volumeName: pv-data and storageClassName set to an empty string, because left unset it would get the default StorageClass where the cluster marks one. Claim and volume name each other, so the binder binds them: it writes the claim UID into the claimRef, and both turn Bound, the old data still on the disk.
Play from step 3 -
If instead the administrator had only cleared the claimRef, pv-data would be Available to any claim that fits it, and volumeName alone reserves nothing. A named volume with no claimRef is checked for class, size, access modes and volume mode, though not node affinity, but a rival matched first takes it: app/scratch binds, and app/restore gets FailedBinding.
Play from step 4