Hands-on Lab·Certified Kubernetes Administrator
Reclaim Policies and Recovering a Released Volume
The emergency lever for a volume you are about to delete, and the four-step recovery that gets the data back afterwards - ending with the file read out of the rebound volume.
Storage Guide 71 of 103 Advanced
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 17 min
PV names are generated by the provisioner. The phases and the claimRef behaviour are the same on any driver.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a claim is about to be deleted and the data has to survive, or when a Released volume must be brought back into service. This matters because Released is not Available - the volume keeps a stale reference that blocks every new claimant until you remove it.
- seeing a dynamically provisioned volume inherit its class's reclaim policy
- patching
persistentVolumeReclaimPolicyon a volume that already exists - the emergency lever - deleting the claim and watching the volume survive as Released
- clearing the stale claimRef and binding a new claim to that volume by name
- checking the data really is still there rather than assuming it
Before you start
- guide 70 - the policies themselves, before this recovers from one.
-
A dynamically provisioned volume, and the policy it inherits
-
Change the policy on the volume that already exists
-
Delete the claim and watch what survives
-
Making it usable again
-
Is the data actually there