21 Kubernetes Storage and Volumes

Kubernetes Storage and Volumes is the set of abstractions Kubernetes provides for attaching durable or ephemeral storage to Pods, decoupling the storage technology underlying a volume from the applications that consume it, and allowing data to persist beyond the lifetime of any single container or Pod when required.

Why Storage Abstractions Are Needed

Containers Are Ephemeral

A container's own filesystem is ephemeral by default, meaning any data written inside it is lost when the container restarts. Applications that need to retain data, or that need to share data between containers in the same Pod, require an explicit storage mechanism layered on top of the container's own filesystem.

Decoupling Storage from Compute

Kubernetes storage abstractions separate the concern of where data physically lives from the concern of which Pod is currently using it, allowing a Pod to be rescheduled to a different node while still reattaching to the same underlying data.

Volumes

Volume Lifecycle Tied to a Pod

A basic Kubernetes volume is defined within a Pod specification and exists for the lifetime of that Pod, surviving container restarts within the Pod but being deleted along with the Pod itself unless it is backed by an external, persistent source.

Common Volume Types

Ephemeral volume types include emptyDir, which provides temporary scratch space shared between containers in a Pod, while other volume types mount data from ConfigMaps, Secrets, or external storage systems directly into a Pod's filesystem.

PersistentVolumes and PersistentVolumeClaims

Decoupling Provisioning from Consumption

A PersistentVolume represents a piece of storage that has been provisioned in the cluster, independent of any specific Pod, while a PersistentVolumeClaim is a request made by a user for storage with certain characteristics, such as size and access mode.

Binding

When a PersistentVolumeClaim is created, it is bound to a PersistentVolume that satisfies its requirements, and a Pod referencing that claim gains access to the underlying storage without needing to know the details of how or where it is provisioned.

Dynamic Provisioning

StorageClasses

A StorageClass describes a category of storage, such as a particular performance tier or backing technology, along with the parameters needed to provision it automatically.

On-Demand Volume Creation

When a PersistentVolumeClaim references a StorageClass, a PersistentVolume can be created automatically and on demand to satisfy that claim, removing the need for an administrator to pre-provision storage manually ahead of time.

Access Modes

ReadWriteOnce, ReadOnlyMany, ReadWriteMany

A PersistentVolume declares one or more access modes describing how it can be mounted: ReadWriteOnce allows read-write access from a single node at a time, ReadOnlyMany allows read-only access from multiple nodes simultaneously, and ReadWriteMany allows read-write access from multiple nodes simultaneously, though not all storage backends support every mode.

Container Storage Interface

A Pluggable Storage Layer

Similar to how the Container Network Interface abstracts networking, the Container Storage Interface (CSI) provides a standardized way for storage vendors to implement drivers that Kubernetes can use to provision, attach, and mount volumes, without requiring storage-specific code inside Kubernetes itself.

Storage Binding Diagram

This layered model, volumes for Pod-scoped storage, PersistentVolumes and claims for durable storage, and StorageClasses for dynamic provisioning, allows Kubernetes to support both stateless workloads with minimal storage needs and stateful applications requiring durable, portable data across the cluster's lifecycle.