Kubernetes Persistent Volumes Explained

Introduction

Containers are designed to be lightweight and ephemeral, meaning their local storage is lost when they are stopped, restarted, or recreated. While this behavior works well for stateless applications, it presents a challenge for applications that need to persist data, such as databases, content management systems, and file storage services.

Kubernetes Persistent Volumes (PVs) provide a reliable way to store data independently of a pod's lifecycle. By separating storage from compute resources, Kubernetes enables applications to retain data even when pods are replaced or rescheduled.

In this article, you'll learn what Persistent Volumes are, how they work with Persistent Volume Claims, and the best practices for managing persistent storage in Kubernetes.

Why Persistent Storage Is Needed

Containers use ephemeral storage by default.

For example, if an application writes files inside a container and the pod is deleted, all those files are lost.

Persistent storage solves this problem by:

Preserving application data
Supporting pod restarts
Enabling stateful applications
Separating storage from containers
Simplifying backup and recovery

This makes persistent storage essential for many production workloads.

What Is a Persistent Volume?

A Persistent Volume (PV) is a storage resource managed by Kubernetes.

Unlike a pod, a Persistent Volume exists independently of any specific workload.

A PV can represent storage from various providers, including:

Azure Disk
Azure Files
Amazon EBS
Google Persistent Disk
NFS
Local storage
CSI-compatible storage systems

Applications consume storage through Persistent Volume Claims rather than accessing the PV directly.

What Is a Persistent Volume Claim?

A Persistent Volume Claim (PVC) is a request for storage made by an application.

Instead of specifying the underlying storage implementation, the application requests:

Storage size
Access mode
Storage class

Kubernetes automatically binds a suitable Persistent Volume to the claim.

This abstraction simplifies storage management across different environments.

Persistent Volume Workflow

The storage lifecycle typically follows these steps:

A storage administrator creates a Persistent Volume or configures dynamic provisioning.
An application creates a Persistent Volume Claim.
Kubernetes binds the claim to a suitable Persistent Volume.
A pod mounts the Persistent Volume Claim.
The application reads and writes persistent data.

This separation provides flexibility and portability.

Persistent Volume vs Persistent Volume Claim

The following table summarizes their roles.

Feature	Persistent Volume	Persistent Volume Claim
Created By	Administrator or Dynamic Provisioner	Application
Represents	Physical or Cloud Storage	Storage Request
Lifecycle	Independent of Pods	Used by Pods
Purpose	Provides Storage	Consumes Storage

Together, PVs and PVCs simplify storage allocation.

Create a Persistent Volume

The following example defines a Persistent Volume.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: app-storage
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/app

This configuration creates a 5 GB Persistent Volume using local storage.

In production, cloud-managed storage is generally preferred over hostPath.

Create a Persistent Volume Claim

Applications request storage using a PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Kubernetes binds the claim to a matching Persistent Volume.

Mount the Persistent Volume

Reference the claim inside a pod.

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
    - name: web-app
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: app-storage
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: app-storage-claim

The application can now store data that persists beyond the pod's lifecycle.

Understanding Access Modes

Persistent Volumes support different access modes depending on the storage provider.

ReadWriteOnce (RWO)

The volume can be mounted as read-write by a single node.

This is commonly used with managed disks.

ReadOnlyMany (ROX)

Multiple nodes can mount the volume, but only for reading.

This is useful for shared reference data.

ReadWriteMany (RWX)

Multiple nodes can read from and write to the same volume simultaneously.

This is commonly supported by network file systems such as Azure Files or NFS.

Choosing the correct access mode depends on your workload requirements.

Dynamic Provisioning

Instead of creating Persistent Volumes manually, Kubernetes can provision storage automatically.

Dynamic provisioning uses Storage Classes.

Example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-storage
provisioner: disk.csi.azure.com

When a PVC references this storage class, Kubernetes automatically creates the required storage resource.

Dynamic provisioning simplifies storage management in cloud environments.

Reclaim Policies

When a Persistent Volume Claim is deleted, Kubernetes applies a reclaim policy.

Common options include:

Retain – Keeps the storage and data after the claim is deleted.
Delete – Deletes the underlying storage resource automatically.
Recycle – Legacy option that is no longer recommended.

Choose the reclaim policy carefully to avoid accidental data loss.

Common Use Cases

Persistent Volumes are commonly used for:

SQL Server databases
PostgreSQL databases
MySQL databases
File uploads
Application logs
Content management systems
Shared application data

Any application requiring durable storage can benefit from Persistent Volumes.

Best Practices

Follow these recommendations when working with Kubernetes Persistent Volumes:

Use dynamic provisioning whenever possible.
Select the appropriate access mode for your workload.
Use cloud-managed storage in production environments.
Implement regular backups for persistent data.
Monitor storage utilization and capacity.
Encrypt sensitive data at rest when supported.
Use meaningful names for Persistent Volumes and Claims.
Test storage recovery procedures regularly.

These practices help ensure reliable and maintainable storage.

Common Mistakes to Avoid

Avoid these common storage-related issues:

Using ephemeral container storage for important data.
Relying on hostPath for production workloads.
Choosing the wrong access mode.
Ignoring backup and disaster recovery requirements.
Underestimating storage capacity needs.
Deleting Persistent Volume Claims without understanding the reclaim policy.
Failing to monitor storage health and usage.

Proper planning helps prevent data loss and downtime.

Persistent Volumes vs Ephemeral Storage

The following comparison highlights the key differences.

Feature	Ephemeral Storage	Persistent Volume
Survives Pod Restart	No	Yes
Suitable for Databases	No	Yes
Shared Across Pods	Depends	Yes, Based on Access Mode
Lifecycle	Tied to Pod	Independent
Best For	Temporary Files	Long-Term Data

Persistent Volumes provide the durability required for stateful applications.

Conclusion

Kubernetes Persistent Volumes provide a reliable and flexible way to manage application data independently of container lifecycles. By separating storage from compute resources, they enable stateful applications to survive pod restarts, rescheduling, and scaling operations without losing critical data.

By understanding the relationship between Persistent Volumes, Persistent Volume Claims, Storage Classes, and access modes, and by following best practices such as dynamic provisioning, appropriate reclaim policies, and regular backups, you can build Kubernetes deployments that are resilient, scalable, and ready for production.