Discover how the policy can affect how your data is managed inside Kubernetes Cluster
As you know, everything is fine on Kubernetes until you face a stateful workload and you need to manage its data. All the powerful capabilities that Kubernetes brings to the game face many challenges when we talk about stateful services that require a lot of data.
Most of the things challenges have a solution today. That is why many stateful workloads such as databases and other backend systems also require a lot of knowledge about how to define several things. One of them is the retain policy of the persistent volume.
First, let’s define what the Reclaim Policy is, and to do that, I will use the official definition from the documentation:
When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.
So, as you can see, we have three options: Retain, Recycle or Delete. Let’s see what the behavior for each of them is.
Retain
That means the data will still be there even if the claim has been deleted. All these policies apply when the original PVC is removed. Before that situation, the data will always remain no matter which policy we use.
So, retain means that even if we delete the PVC, the data will still be there, and it will be stored so that no other PVC can claim that data. Only an administrator can do so with the following flow:
- Delete the PersistentVolume.
- Manually clean up the data on the associated storage asset accordingly.
- Manually delete the associated storage asset.
Delete
That means that as soon as we remove the PVC the PV and the data will be released.
This will simplify the cleanup and housekeeping task of your volumes but at the same time, it increases the possibility that has some data loss because of unexpected behavior. As always, this is a trade-off you need to do.
We always need to remind you that if you try to delete PVC in active use by a Pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any Pods to ensure that no data is lost, at least when some component is still bound to it. On the same policy similar thing happens to the PV. If an admin deletes a PV attached to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is no longer bound to a PVC.
Recycle
That means something in the middle works similar to the Delete policy we explained above, but it doesn’t delete the volume itself, but it will remove the content of the PV, so in practice, it will be similar. So, in the end, it will perform a command similar to this rm -rf on the storage artifact itself.
But just for you to be aware, this policy is nowadays deprecated, and you should not use it in your new workloads, but it is still supported so you can find some workloads that are still using it.
Related articles:
AccessModes Eases The Path To Stateful Workloads Running on Kubernetes Platform 
Kubernetes Autoscaling: Learn How to Scale Your Kubernetes Deployments Dynamically 
AWS Prometheus Service to Provide More Availability to Your Monitoring Solution 
EKS Hybrid Series: Changing namespaces of serverless deployment