Persistent Volume in Kubernetes


Volumes were great as they saves us from data lost just in case of container restart.
Volumes hold data at a pod level but questions could also be asked what if for any reason Kubernetes terminates the pod e.g rescheduling the pod.
within the case of pod termination data within the volumes are going to be lost.
To unravel this issue Kubernetes provides us an option for Persistent Volume.
Persistent Volume puts a volume at a cluster level instead of pod level.
We create a Persistent Volume resource during which we provide cluster level volume which will be employed by any pod.
The pod may use that Persistent Volume by using another resource Persistent Volume claims.
It is always available outside of the pod life cycle.
The meaning volume will remain even after the pod is deleted.
This volume is going to be available to say by another pod if required, and therefore the data is retained.

POD → Persistent Volume claim → Persistent Volume

 Persistent Volume Claim

It’s a sort of formal request from a user for claiming a persistent volume.
The persistent volume claim explains the quantity and characteristics of the storage required by the pod.
the supported requirement from user PVC finds any matching Persistent Volumes and claims it.
counting on the configuration options used for Persistent Volume resource, this PV resource can later be used/claim by other pods.

Understanding Persistent Volume Specs

sorts of access Modes

ReadWriteOnce (Only one node can mount the quantity for reading and writing)
ReadOnlyMany (Multiple nodes can mount the quantity for reading)
ReadWriteMany (Multiple nodes can mount the quantity for both reading and writing)
RWO, ROX, and RWX pertain to the number of worker nodes that will use the quantity at an equivalent time, not the number of pods!

Persistent Volume Reclaim Policy

We’ve learned that counting on the configuration options used for the Persistent Volume resource, this PV resource can later be used/claim by other pods.
The lifetime of a Persistent Volume is decided by its reclaim policy.
The Reclaim policy took care of the action the cluster would take when a pod releases its ownership of the storage.
Persistent Volume Reclaim Policy tags are often utilized in the YAML configuration file at the time of making PV.

Reclaim Policies are often set to

Delete (Persistent Volume are going to be deleted when the PVC is deleted but data will persist)
Recycle (Volume’s content are going to be deleted, persistent volume are going to be available to be claimed again)
Retain (Default)
If persistent volume Reclaim Policy is not described, Retain is the default.
Kubernetes will retain the quantity and its contents after it’s released from its claim.
To form persistent volume available again for claims are often done by deleting and recreating the persistent volume resource manually.
The underlying storage can either delete or be left to be reused by a subsequent pod.

Mansoor Ahmed

Mansoor Ahmed is Chemical Engineer, web developer, a Tech writer currently living in Pakistan. My interests range from technology to web development. I am also interested in programming, writing, and reading.