All diagrams
Storage: Volumes & Claimsk8s 1.36

PV Lifecycle Phases

What does the phase of a PersistentVolume track, and who moves it? The PV controller in kube-controller-manager writes it: a bound claim makes it Bound, a deleted claim makes it Released, as the stale claimRef stays. Under Delete a CSI volume leaves the row once DeleteVolume succeeds, Failed means reclamation failed, for instance when no plugin can delete it, and short of the deprecated Recycle the way back is clearing the claimRef by hand, old data included.

Play the animation 5 steps, animated, best on a wide screen

PV Lifecycle Phases diagram: The phase of a PersistentVolume as a status field on a row of four places, Available,

PV Lifecycle Phases, step by step

  1. A new claim asks for storage. Under the default Immediate binding mode, the PV controller finds this volume, writes the claim into its claimRef and sets the phase to Bound. The claim itself writes nothing: every phase on this row is written by the controller, in response to events like this one.

    Play from step 1

  2. The claim is deleted. Its claimRef now names a claim that no longer exists, so the controller writes Released, not Available. That stale reference stays on the PV, and it is exactly what stops any other claim from binding. What happens next depends on the reclaim policy.

    Play from step 2

  3. If the policy is Delete, the PV controller does not delete a CSI volume. The external-provisioner does: it calls DeleteVolume on the driver and then deletes the PV object itself. There is no final phase to write, because the volume leaves this row altogether.

    Play from step 3

  4. If instead the volume is a hand-made NFS PV set to Delete, no plugin can delete it. The controller finds no deleter and writes Failed, with a VolumeFailedDelete event. A CSI volume set to Delete does not land here: its failed DeleteVolume is retried while it stays Released.

    Play from step 4

  5. Short of the deprecated Recycle policy, which scrubs a volume and frees it on its own, the way back is by hand. An administrator removes the stale claimRef, and the controller writes Available, from Released or from Failed alike. A matching claim can now bind it, with the previous data still on it.

    Play from step 5

Sources

Commands for this