DevOps Dictionary

Kubernetes PersistentVolume (PV) is a cluster-level storage resource that represents a piece of durable storage available to pods. A PersistentVolume lets application data survive pod restarts, rescheduling, and container replacement, as long as the underlying storage remains available.

In practical terms, a PV is how Kubernetes connects workloads to storage systems such as cloud disks, NFS shares, Ceph volumes, or CSI-backed storage. Pods do not usually mount PVs directly. They request storage through a PersistentVolumeClaim, and Kubernetes binds the claim to a matching volume.

What a PersistentVolume does

A PV gives Kubernetes a way to manage storage separately from application pods. This matters because pods are temporary by design, while many applications need stable data.

• Preserves data: Data can remain available after a pod crashes, restarts, or moves to another node.
• Decouples storage from workloads: Platform teams can manage storage options while developers request storage through claims.
• Supports different storage backends: PVs can map to cloud block volumes, network filesystems, or storage provisioned through Container Storage Interface drivers.
• Controls lifecycle behavior: A PV can retain, delete, or recycle data depending on its reclaim policy.

How it works

A typical flow looks like this:

1. An administrator creates a PersistentVolume manually, or Kubernetes provisions one dynamically through a StorageClass.
2. A developer creates a PersistentVolumeClaim that requests storage, such as 20Gi with read-write access.
3. Kubernetes finds a matching PV or creates one through dynamic provisioning.
4. The pod references the claim and mounts the storage into the container filesystem.

For example, a PostgreSQL pod might mount a claim at /var/lib/postgresql/data. If the pod is deleted and recreated, Kubernetes can attach the same storage again, so the database files remain available.

PV, PVC, and StorageClass

These three terms are closely related, but they serve different roles:

• PersistentVolume: The actual storage resource in the cluster.
• PersistentVolumeClaim: A request for storage made by a workload or developer.
• StorageClass: A template that defines how storage should be dynamically provisioned, such as disk type, filesystem, or cloud storage class.

Think of the PVC as the application’s storage request, the PV as the storage that satisfies the request, and the StorageClass as the provisioning policy behind it.

Common use cases

• Databases: PostgreSQL, MySQL, MongoDB, Redis with persistence, and other stateful workloads.
• Message brokers: Kafka, RabbitMQ, and other systems that need durable queues or logs.
• CI/CD systems: Build caches, artifact storage, and workspace persistence.
• Data platforms: Tools such as Airflow, Spark components, or workflow engines that need persistent metadata or logs. For example, storage planning is part of many production setups when you deploy Apache Airflow on AWS EKS.
• Shared file storage: Applications that need multiple pods to read from the same filesystem, depending on the access mode supported by the backend.

Key PersistentVolume fields

• capacity: Defines the size of the volume, such as 10Gi or 100Gi.
• accessModes: Controls how the volume can be mounted, such as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany.
• persistentVolumeReclaimPolicy: Defines what happens when the claim is deleted. Common values are Retain and Delete.
• storageClassName: Connects the PV to a StorageClass.
• volumeMode: Defines whether the volume is exposed as a filesystem or raw block device.
• csi: Defines storage managed by a CSI driver, which is the standard way Kubernetes integrates with modern storage providers.

Static and dynamic provisioning

PersistentVolumes can be created in two main ways:

• Static provisioning: A cluster administrator creates PVs ahead of time. Developers then create PVCs that bind to those existing volumes.
• Dynamic provisioning: Kubernetes creates a PV automatically when a PVC requests storage through a StorageClass.

Most cloud-native clusters use dynamic provisioning because it reduces manual storage setup. On AWS, for example, a PVC can trigger creation of an EBS volume through the EBS CSI driver. Infrastructure teams may manage these Kubernetes resources with GitOps or infrastructure-as-code tools, including workflows that deploy Kubernetes resources using Terraform.

Access modes

Access modes define how a volume can be mounted by nodes and pods:

• ReadWriteOnce: The volume can be mounted as read-write by a single node. This is common for cloud block storage.
• ReadOnlyMany: The volume can be mounted as read-only by many nodes.
• ReadWriteMany: The volume can be mounted as read-write by many nodes. This usually requires a shared filesystem such as NFS, EFS, or another compatible backend.
• ReadWriteOncePod: The volume can be mounted as read-write by a single pod, supported by newer Kubernetes versions and CSI drivers.

The storage backend must support the requested access mode. A PVC asking for ReadWriteMany will not bind to a block volume that only supports ReadWriteOnce.

Benefits

• Durability for stateful workloads: Data can outlive individual pods.
• Cleaner separation of concerns: Developers request storage, while platform teams define storage classes and policies.
• Cloud and storage-provider flexibility: CSI drivers allow Kubernetes to work with many storage systems.
• Automation-friendly: PVs and PVCs can be managed through manifests, Helm charts, Terraform, Crossplane, or GitOps pipelines.

Tradeoffs and limitations

• Storage is still provider-specific: Kubernetes abstracts storage requests, but performance, attach limits, snapshots, and replication depend on the backend.
• Stateful workloads need careful scheduling: A pod may need to run in the same zone as its volume, especially with zonal block storage.
• Reclaim policies can cause data loss: A Delete policy may remove the underlying disk when the PVC is deleted.
• Backups are separate: A PV is persistent storage, but it is not a backup strategy. You still need snapshots, backups, and restore testing.
• Upgrades require planning: CSI drivers, StorageClasses, and StatefulSets should be checked before cluster upgrades. Storage behavior is one of the areas to review when applying practical Kubernetes upgrade steps for startups.

Simple example

A team runs a small internal PostgreSQL service on Kubernetes. The database pod uses a PVC requesting 50Gi of storage. Kubernetes provisions a PV backed by a cloud disk and mounts it into the pod.

If the pod crashes, Kubernetes starts a replacement pod and mounts the same volume. The PostgreSQL data directory is still there. If the team deletes the PVC and the PV has a Delete reclaim policy, the underlying disk may be removed too. If the PV has a Retain policy, the disk remains for manual recovery or cleanup.

How PVs fit into platform workflows

In production clusters, PersistentVolumes are usually part of a wider platform setup. Teams define StorageClasses, default reclaim policies, encryption settings, backup rules, and workload patterns for StatefulSets.

Some teams also manage cloud infrastructure and Kubernetes resources through Kubernetes APIs. For example, Crossplane can provision cloud resources from inside the cluster, which can be useful when you deploy AWS resources using Crossplane on Kubernetes.

PersistentVolume vs emptyDir

emptyDir is temporary storage created when a pod starts. It is deleted when the pod is removed from the node. A PersistentVolume is designed for data that should survive pod replacement.

• Use emptyDir for scratch space, temporary files, and short-lived caches.
• Use a PersistentVolume for databases, durable queues, uploaded files, and application state.

In short

A Kubernetes PersistentVolume is the durable storage object behind stateful workloads in a cluster. It works with PersistentVolumeClaims and StorageClasses to give pods stable storage without tying application manifests directly to a specific disk or storage system.