Kubernetes Storage

Containers have a storage problem by design: their on-disk files are ephemeral, lost on every crash and restart, and invisible to the other containers in the same Pod. Kubernetes storage is the set of abstractions that fixes this — from scratch space that lives exactly as long as a Pod, to durable volumes that outlive Pods, nodes, and even the applications that created them.

The mental model: Kubernetes separates what storage a workload needs from what storage the infrastructure provides, with a matchmaking layer in between. Applications claim storage in abstract terms ("10 GiB, writable by one node at a time"); administrators or automation supply concrete volumes; the platform binds the two. That separation — claim, class, volume — is nearly the entire subject.

Volumes: storage attached to a Pod

The basic unit is the volume: a directory made available to the containers in a Pod, mounted at a path each container chooses. Volumes solve both ephemerality problems at once — data can survive container restarts, and containers in a Pod can share files through a common mount.

Ephemeral volumes live and die with the Pod: emptyDir for scratch space and inter-container sharing, configMap and secret volumes for injecting configuration as files, downwardAPI for exposing Pod metadata, and generic ephemeral volumes for per-Pod provisioned scratch storage. Persistent volumes outlive the Pod — this is where databases, queues, and anything with real state lives. A special mention for hostPath, which mounts a node directory into a Pod: legitimate for node-level agents, and a well-documented security foot-gun for everything else.

PersistentVolumes and PersistentVolumeClaims

Durable storage revolves around two objects. A PersistentVolume (PV) is a piece of storage in the cluster — an API object capturing the details of an NFS share, a cloud disk, whatever the infrastructure offers. A PersistentVolumeClaim (PVC) is a workload's request for storage: size, access mode, and optionally a class. Kubernetes binds claims to suitable volumes, and Pods then reference the claim — never the volume directly. The claim is the portable part: the same manifest works on any cluster that can satisfy it, which is exactly the point.

Access modes describe how a volume may be attached: ReadWriteOnce (one node read-write — note: node, not Pod), ReadOnlyMany, ReadWriteMany (many nodes simultaneously — only some storage systems can), and ReadWriteOncePod (exactly one Pod). What happens to a released volume is the reclaim policy: Delete removes the underlying storage with the claim; Retain keeps volume and data for manual handling.

StorageClasses and dynamic provisioning

Pre-creating PVs by hand (static provisioning) doesn't scale past a handful of workloads. A StorageClass describes a kind of storage — which provisioner to use, with which parameters (disk type, replication, filesystem) — and dynamic provisioning creates PVs on demand: a PVC naming a class triggers the provisioner to create exactly the volume claimed. A cluster can mark one class as default, making storage self-service for developers. The volumeBindingMode: WaitForFirstConsumer setting delays provisioning until a Pod is scheduled, so the volume lands in the right zone — the fix for a classic multi-zone failure mode.

CSI: how storage systems plug in

The Container Storage Interface (CSI) is the standard by which storage vendors integrate: a driver deployed into the cluster exposes provisioning, attaching, mounting, snapshots, and expansion for that storage system. In-tree cloud volume plugins have been migrated out to CSI drivers; practically, all real storage in modern clusters flows through CSI. On top of it sit the advanced features: volume snapshots (point-in-time copies via VolumeSnapshot objects), volume cloning, and volume expansion (grow a PVC where the class allows it).

Who needs this, and when

Anyone deploying anything stateful — which eventually is everyone. Application engineers mostly write PVCs and pick classes; platform teams design the classes, install CSI drivers, and set reclaim and expansion policy; both share responsibility for the part Kubernetes deliberately doesn't do: backup.

Limits and honest caveats

Kubernetes orchestrates storage; it does not be storage. Performance, durability, and failure semantics come from the underlying system, and the abstractions faithfully pass those properties through — including the disappointing ones. ReadWriteMany is not a default capability. Snapshots are crash-consistent, not application-consistent, unless you quiesce the application. Deleting a StatefulSet leaves its PVCs behind (deliberately), and a Delete reclaim policy on precious data is a resume-generating event. Treat storage classes, reclaim policies, and backup strategy as one design conversation, not three afterthoughts.