A Crash Course in Persistent Kubernetes Storage

Application containers are prized for their portability and scalability, but storage has historically been a pain point. Early container runtimes only suited stateless workloads — front-end web apps were fine, but databases and anything else requiring durable data were problematic. Kubernetes has largely solved this through a layered storage model built around a handful of well-defined objects.

Why Containers Originally Struggled with Persistent Storage

Containers are ephemeral by design. When a container process ends, its writable layer is discarded. This made containers excellent for stateless services but unsuitable for workloads that need to survive restarts or be shared across multiple container instances. Kubernetes addresses this by externalising storage from the pod lifecycle entirely.

The Two High-Level Tasks for Persistent Kubernetes Storage

To use persistent storage in Kubernetes you need to accomplish two things:

1. Attach a physical (or cloud) storage device to the Kubernetes cluster. This is done through a storage driver, ideally via the Container Storage Interface (CSI).
2. Grant the application access to that storage. This is done through Kubernetes storage objects — PersistentVolumes, PersistentVolumeClaims, and StorageClasses.

The Container Storage Interface (CSI)

The Container Storage Interface (CSI) is the standard mechanism for connecting an external storage system to a Kubernetes cluster. Before CSI existed, storage drivers had to be compiled directly into the Kubernetes codebase, which made adding or updating drivers slow and risky. CSI decouples storage drivers from the core Kubernetes binary, allowing storage vendors to ship and update drivers independently. CSI drivers are deployed as pods inside the cluster and communicate with the Kubernetes control plane through a well-defined API. Beyond flexibility, CSI also provides a consistent security boundary between the storage backend and the orchestrator.

PersistentVolumes (PVs)

A PersistentVolume (PV) is a cluster-level storage resource that exists independently of any pod. Think of it like a pre-provisioned virtual hard disk: it has a defined capacity, a filesystem, a name, and an access mode (e.g. ReadWriteOnce, ReadOnlyMany, or ReadWriteMany). Critically, its lifecycle is not tied to any pod. You can delete the pod that was using a PV and the PV — along with the data on it — remains intact until an administrator explicitly removes it.

PVs can be created in two ways:

• Static provisioning: An administrator manually creates PV objects in the cluster ahead of time.
• Dynamic provisioning: Kubernetes creates PVs on demand in response to a PersistentVolumeClaim, using a StorageClass to determine how to provision the backing storage.

PersistentVolumeClaims (PVCs)

A newly created PV is an isolated object — it is not attached to any pod or workload. The bridge between a pod and a PV is a PersistentVolumeClaim (PVC).

A PVC is a request for storage made by a namespace. It specifies the desired capacity, access mode, and optionally a StorageClass. Kubernetes matches the claim to a suitable PV (or dynamically provisions one) and binds them together. The pod then mounts the PVC as a volume, gaining access to the underlying storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Once bound, the PVC is referenced inside a pod’s volume specification:

volumes:
  - name: app-storage
    persistentVolumeClaim:
      claimName: my-app-pvc

StorageClasses

When you need many application instances, each requiring its own persistent storage, manually creating PVs and PVCs for every instance becomes unmanageable. A StorageClass solves this by defining a template for dynamic volume provisioning.

A StorageClass tells Kubernetes how to provision storage: which CSI driver to use, what parameters to pass (disk type, replication factor, IOPS tier, etc.), and what reclaim policy to apply when a PVC is deleted. When a PVC references a StorageClass, Kubernetes automatically creates a matching PV using that class’s provisioner — no administrator intervention required.

A StorageClass also serves as an organisational tool. You can define multiple classes — for example, fast-ssd for latency-sensitive databases and standard-hdd for bulk data — and let application teams choose the appropriate tier via their PVC definition.

How the Pieces Fit Together

The flow for dynamic provisioning looks like this:

1. An administrator defines one or more StorageClasses, each backed by a CSI driver.
2. A developer (or automated deployment tool) creates a PersistentVolumeClaim referencing the desired StorageClass and capacity.
3. Kubernetes dynamically provisions a PersistentVolume via the CSI driver and binds it to the PVC.
4. The pod mounts the PVC as a volume and the application reads/writes data normally.
5. When the pod is deleted, the PV and its data survive. The reclaim policy on the StorageClass determines what happens to the PV when the PVC itself is deleted (typically Retain or Delete).

Key Concepts at a Glance

Further Reading

The official Kubernetes documentation on persistent volumes covers access modes, reclaim policies, volume binding modes, and topology constraints in detail and is the authoritative reference for production use.