liveBook · Manning

Reclaim policy

As explained in Kubernetes in Action, Second Edition

The reclaimPolicy field is a StorageClass configuration field that sets the reclaim policy for provisioned PersistentVolumes.

A reclaim policy determines what happens to a PersistentVolume after its PersistentVolumeClaim is deleted. The StorageClass sets this through reclaimPolicy; the resulting PersistentVolume records the setting as persistentVolumeReclaimPolicy. Deleting a pod alone does not release the claim or volume. section 10.2.3 section 10.3.3

Choose the policy according to whether the underlying data should survive claim deletion:

  • Retain keeps the PersistentVolume and underlying storage after release; an administrator must manually reclaim it. Manually created volumes typically use this policy. section 10.2.3 section 10.3.3
  • Delete removes the PersistentVolume object and underlying storage automatically after release. Dynamically provisioned volumes typically use it. section 10.2.3 section 10.3.3
  • Recycle is deprecated and may not be supported; it typically deletes the volume's files and makes the volume available again. section 10.2.3

A claim becomes released

After deleting a pod and its claim with `kubectl delete pod quiz` and `kubectl delete pvc quiz-data`, inspect the volume with `kubectl get pv quiz-data`. A volume using Delete shows status Released before Kubernetes deletes it; a Retain volume remains for manual handling. section 10.2.3

Table 10.3 Persistent volume reclaim policies
Reclaim policy
Description
Retain
When the PersistentVolume is released (this happens when you delete the claim that’s bound to it), Kubernetes retains the volume. The cluster administrator must manually reclaim the volume. This is the default policy for manually created PersistentVolumes.
Delete
The PersistentVolume object and the underlying storage are automatically deleted upon release. This is the default policy for dynamically provisioned PersistentVolumes, which are discussed in the next section.
Recycle
This option is deprecated and shouldn’t be used as it may not be supported by the underlying volume plugin. This policy typically causes all files on the volume to be deleted and makes the PersistentVolume available again without the need to delete and recreate it.

Compare Retain, Delete, and deprecated Recycle behavior in the policy table. section 10.2.3

A Released volume is not immediately reusable because it may still contain data from the previous claim. With Retain, delete and recreate the PersistentVolume object to make pre-provisioned storage available again; the object is a pointer, not the stored data. section 10.3.3

Change a volume from Delete to Retain before deleting a claim when the data must survive. Changing a Released volume from Retain to Delete can delete both the PersistentVolume object and underlying storage. section 10.2.3

How Kubernetes in Action, Second Edition covers it

How deep it goes
Explains policy values, lifecycle states, defaults, reuse, and policy changes, but does not show a complete StorageClass manifest.
Examples
Uses kubectl deletion and inspection commands to show a volume changing from Bound to Released.
What it assumes
Assumes PersistentVolume and PersistentVolumeClaim concepts while distinguishing pod deletion from claim deletion.
What you can do after
Operate/configure storage retention safely and identify when claim deletion may destroy underlying data.
How it connects
Connects StorageClass, PersistentVolume, PersistentVolumeClaim, dynamic provisioning, static provisioning, and StatefulSet retention.

Also explained in

Compare how 3 books explain reclaim policy →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.