The Ultimate Guide to Persistent Volumes: Best Practices Unveiled

The PVC-to-PV binding ignores some volume-matching criteria, including node affinity. But the control plane still checks that the storage class and access modes are valid.

Configure the Storage Class

The storage class is an object in Kubernetes that captures details about your cluster’s storage implementation. Whether that’s NFS, cloud provider-specific storage systems, or iSCSI, the storage class makes managing data independent of applications accessible.

The key feature of the storage class is that it allows administrators to describe different classes of storage based on qualities such as quality-of-service levels, backup policies, and more. Storage classes can be used for both static and dynamic provisioning. When a persistent volume claim specifies the storage class name in its storage requirements, a control loop watches for existing PVs that match those specifications and bind them together.

This is especially important when it comes to latency-sensitive apps like databases. You can reduce latency and improve performance by ensuring that the physical replica of a persistent volume is located close to where the application runs.

If you don’t specify a storage class for a PVC, the default storage class in your cluster will be used, which can cause unpredictable behavior. To avoid this, always specify a storage class for every PVC. When a PVC is reclaimed, the reclaim policy specified in the storage class will determine what happens to the underlying PV. The reclaim policy can be set to Retain, Recycle, or Delete.

Define a Reclaim Policy

The reclaim policy for a persistent volume determines what happens to the underlying storage when the PVC object is released. Reclaim policies include Retain, Recycle, and Delete. The default is Retain, which retains the data and allows it to be manually reclaimed by an administrator. It’s a good idea to use reclaim policies that ensure your most critical data is recoverable in the event of accidental deletion.

Kubernetes persistent volume best practices allow ephemeral containers to store data that isn’t deleted when the pod is rebooted or updated. Persistent volumes also provide a mechanism for stateful applications to store data that are not accessible by other containers in the same pod.

To use persistent volumes, you need to create a PersistentVolumeClaim object. The PVC specifies the size and access mode (ReadOnlyOnce, ReadWriteOnce, or ReadOnlyMany) that the persistent storage should support. 

A pod uses the PVC’s namespace to locate the persistent volume that backs the claim, which is then mounted to the pod. 

Create a PersistentVolumeClaim

A PersistentVolumeClaim is a Kubernetes object that defines the volume to which a pod will mount. Persistent volumes support stateful applications, such as databases and container logs. These volumes must be persistent to survive a pod shutdown or crash.

When a pod creates a PersistentVolumeClaim, the volume creation is dynamic and performed by a StorageClass (more on this in the next part of this series). This eliminates the need to configure persistent storage for each pod manually. This also allows the pod to use the exact PVC across multiple clusters and environments.

Pods that access a PersistentVolume must be bound to it to have read-write privileges on the data stored in the volume. This can be done using a volume claim template that specifies a list of claims. The claim is then matched against the volume mounts in a pod to select a persistent volume that matches it.

When a pod no longer needs a PersistentVolumeClaim, it must be deleted. This frees up the storage and reclaims it for use by another pod. However, the associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, or Cinder volume) may still contain unrecoverable data from a previous pod that used the PersistentVolumeClaim. For this reason, it is best to use a backup solution, such as Velero, to automate the creation of backups for persistent volumes and PersistentVolumeClaims.

Create a PersistentVolume

Before you create a PersistentVolume, you must ensure the cluster’s storage infrastructure is ready. This includes correctly setting up the correct StorageClass, defining a PersistentVolumeClaim, and configuring the storage class’s reclaim policy. The reclaim policy dictates what happens to a persistent volume when it’s no longer bound to a PVC. Depending on the reclaim policy’s configuration, it can be retained, recycled, or deleted.

A persistent volume is a storage object that connects to back-end storage through a series of abstractions. It’s a convenient way for developers to access their data without knowing the details of the cloud environment they’re working in. It’s essential to choose the right persistent volume for your application. For example, you should store database files in a persistent volume so that they’ll survive a pod shutdown or crash. It would be best if you also wrote container logs to a persistent volume so that they’re available after the pod restarts.

A PersistentVolumeClaim is a Kubernetes resource that binds to a persistent volume. It contains the specification of a back-end storage object and a mount path that will be used to access the volume. PersistentVolumeClaims can only be mounted by pods that request the same storage class. It’s also essential to choose the proper access mode.