Kubernetes Storage: Persistent Volumes Explained

Containers are ephemeral by design: data stored inside a container is lost when the container is restarted or replaced. Kubernetes provides PersistentVolumes (PVs) to give containers durable storage that survives pod lifecycle events.

The Problem

A database running in a Kubernetes pod stores its data on the container's filesystem. If the pod is rescheduled to a different node (due to failure, scaling, or maintenance), the new pod starts with a fresh filesystem and all data is lost.

Persistent storage solves this by decoupling storage from the pod lifecycle.

PersistentVolumes (PV)

A PersistentVolume is a piece of storage provisioned in the cluster. It has a lifecycle independent of any pod. PVs can be backed by: - Cloud block storage (EBS, Persistent Disk, etc.) - NFS shares - Local storage on a node - Distributed storage systems (Ceph, GlusterFS)

PersistentVolumeClaims (PVC)

A PersistentVolumeClaim is a request for storage by a pod. It specifies the size, access mode, and optionally the storage class needed. Kubernetes binds the PVC to an available PV that matches the requirements.

StorageClasses

StorageClasses define different types of storage available in the cluster (fast NVMe, standard SSD, etc.). They enable dynamic provisioning: when a PVC requests a StorageClass, the provisioner automatically creates a PV.

Dynamic provisioning eliminates the need for administrators to pre-provision PVs. The storage is created on-demand when a pod requests it.

Access Modes

PVs support different access modes: - ReadWriteOnce (RWO): mounted by a single node - ReadOnlyMany (ROX): mounted by multiple nodes as read-only - ReadWriteMany (RWX): mounted by multiple nodes as read-write

Not all storage backends support all access modes. Block storage typically supports only RWO.

Using Persistent Storage

A pod references storage through a PVC: 1. Create a PVC requesting the desired size and storage class 2. Mount the PVC in the pod's container at a specific path 3. The container reads and writes to the mounted path 4. Data persists across pod restarts and rescheduling

StatefulSets

StatefulSets are the Kubernetes workload type for stateful applications (databases, message queues). They provide: - Stable, persistent storage per pod - Stable network identities - Ordered deployment and scaling - Each pod in a StatefulSet gets its own PVC, ensuring data isolation

Best Practices

• Use dynamic provisioning with StorageClasses rather than static PVs
• Set appropriate access modes for your workload
• Use StatefulSets for databases and other stateful applications
• Implement backup strategies for persistent data
• Monitor storage usage and plan capacity
• Consider storage performance (IOPS, latency) when selecting storage classes

Understanding Kubernetes storage primitives enables you to run stateful applications reliably alongside your stateless workloads.

Key Takeaways

• PersistentVolumes decouple storage from pod lifecycles, ensuring data survives pod restarts and rescheduling to different nodes
• StorageClasses enable dynamic provisioning — storage is created on demand when a PVC is submitted, eliminating manual pre-provisioning
• Access modes (RWO, ROX, RWX) determine how many nodes can mount a volume; block storage typically supports only single-node access
• StatefulSets provide stable storage, stable network identities, and ordered deployment for stateful workloads like databases and message queues
• Always implement a backup strategy for persistent data, since PVs protect against pod loss but not storage-level failures