Kubernetes 101 : Pods and persistent storage.

Persistent data in kubernetes:

When running a database pod, if the pod crashes and a new pod get redeployed, the database data will be lost.

Persistent volumes solve the issue.

There are a couple of components related to persistent storage in kubernetes:

  • Persistent volume.
  • Persistent volume claim.
  • Storage class.
Persistent storage:

We need a storage that is not tied to the lifetime of the pod, so even if the pod crashes, the data stays intact.

The new redeployed pod will attach itself to the persistent storage, so it will have the same data as the pod that crashed before.


Since the new pod could be redeployed on any node, we would need a storage that is accessible throughout the cluster.

Persistent volume:

Persistent volume is created like the other kubernetes components though a YAML configuration file.

The example above is of a local persistent storage with a capacity of "10Gi" accessible at "/mnt/pv".
Local persistent storage are not a viable option, since they are tied to a node and if the node crashes, the data gets destroyed.

Remote persistent storage:

A persistent remote storage could be NFS or cloud storage.
Different storages have different parameters in their configuration YAML file.
For NFS the file would have an NFS server , a path in the NFS server,...


These persistent volumes need to be available throughout the whole cluster, they can't exist in a namespace.

Persistent Volume Claim:

In order to use a persistent storage applications running inside a pod need to "claim the storage".
Applications can claim a storage using the persistent volume claim.
PVC or persistent volume claim is created using a YAML configuration file.

A persistent volume claim have certain characteristics, like access modes, capacity,..
Whatever a storage that satisfies these characteristics, it will be chosen by the persistent volume claim.

Pods interacts with the persistent volume claim through their configuration file. 
The pod's YAML has a section dedicated to persistent volume claim:

Pod_1 uses the persistent volume claim PVC1 to request the storage.

All the containers in the Pod will have access to the storage with the 10Gi capacity (Storage parameter in the PVC YAML file).


Persistent volume claim needs to be in the same namespace as the pod.

Once the PVC finds the storage, it will be mounted on the pod, and the volume will be mounted in the container on the mountPath as we can see in the below YAML file of the pod.

Applications can access data in the volume. If the pod crashes, the replacement pod will have access to the same data.

Storage class:

Persistent volumes need to be created before deploying applications that are going to use them.
When we have a lot of applications, creating persistent volumes manually for each application is not practical.
Storage class helps create volumes dynamically when persistence volume claim requests them.
Storage class automates the creation of volumes.
Storage class is created using a YAML file:

Provisioner: each storage needs to be created in a provisioner, in our example it's kubernetes.io/aws-ebs.

Below, is the persistent volume claim YAML configuration file:

The PVC makes a request to StorageClass_1 to create a storage (size: 50Gi, readwriteonce,...).
StorageClass_1 provisions the storage in kubernetes.io/aws-ebs (with certain IOPS, filesystem type,...).

: persistent volume claim.


Leave as a comment: