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:
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:
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.