Skip to main content
This section shifts focus from compute topics—architecting the platform, sizing resources, isolating tenants, and governing usage—to the second pillar of platform engineering: storage. By the end of this lesson you’ll understand how PersistentVolumeClaims (PVCs), PersistentVolumes (PVs), and StorageClasses work together in Kubernetes. You will know how to provision storage (static vs dynamic), the three access modes and backend support for each, and how to match workload requirements to the right storage configuration for performance, availability, and cost.
The image lists learning objectives related to PersistentVolumes, PersistentVolumeClaims, and StorageClasses in Kubernetes, focusing on roles, provisioning, access modes, and backend support.
Start with a real problem. A startup deployed PostgreSQL in Kubernetes without persistent volumes. During a routine cluster upgrade the node was drained, the Postgres pod restarted on a different node, and the container filesystem was empty. Six hours of customer transactions were lost.
This is not a hypothetical risk—running stateful services on ephemeral container storage can and will lead to data loss during node maintenance, evictions, autoscaling, and failures.
The image illustrates data loss in a Kubernetes cluster when Postgres runs on ephemeral storage, highlighting the transition from an "Original Node" to an "Upgraded Node" which results in a loss of six hours of data. It emphasizes the importance of configuring persistent volumes.
Why did this happen? Containers are disposable: when a pod is removed (crash, eviction, reschedule), the container runtime deletes the writable layer that contains any data written to the container filesystem. For example, a pod that had written 500 MiB will restart with 0 MiB unless that data was stored outside the ephemeral layer.
The image illustrates the lifecycle of a container with three states: active (running with local data), failure (pod crashed), and new pod (empty new instance), showing how containers lose data after crashes.
This is by design: containers are stateless and replaceable. Stateless workloads—web servers, API frontends, functions—are fine with ephemeral storage. Stateful workloads—databases, message queues, file stores—require durable storage that survives pod replacement. The solution is to attach external storage that outlives a pod. Kubernetes mounts that storage into the pod as a filesystem so the pod can be replaced while the data remains intact on the volume.
The image illustrates a Kubernetes cluster with a compute layer containing an initial and new pod, connected to persistent volume storage, highlighting storage persistence despite pod changes.

​
Kubernetes storage stack (three layers)

Understanding which component creates and manages what is essential for platform teams and developers.
The image illustrates the Kubernetes Storage Stack, showing the relationship and flow between Pod, PersistentVolumeClaim (PVC), PersistentVolume (PV), and StorageClass.
From bottom to top:
  • StorageClass — A template or “menu entry” that defines how volumes are provisioned. It points to a CSI driver (the provisioner) and includes provider-specific parameters such as disk type, IOPS, encryption, and topology constraints. Platform teams create and manage StorageClasses for developers to choose from.
  • PersistentVolume (PV) — A representation of an actual storage resource. PVs are either:
    • statically provisioned by admins (manually created), or
    • dynamically provisioned by a StorageClass when a PVC is requested. Cloud environments typically use dynamic provisioning.
  • PersistentVolumeClaim (PVC) — A developer’s request for storage. The PVC declares size, access mode(s), and optionally a StorageClass name. Kubernetes attempts to find an existing matching PV or asks the StorageClass to provision one, then binds the PVC to that PV. A pod mounts the PVC as a directory (for example, /data).
Analogy: StorageClass is the menu, PVC is your order, PV is the dish, and the Pod consumes it. If a diner (pod) leaves, the dish (data) stays.

​
Access modes

Access modes define how a volume may be mounted and how many nodes/pods can use it. Not all modes are supported by every backend.
  • ReadWriteOnce (RWO): mount read-write by a single node (multiple pods on that node may share). Typical for block volumes and databases.
  • ReadOnlyMany (ROX): mount read-only by many nodes. Good for distributing static assets across replicas.
  • ReadWriteMany (RWX): mount read-write by many nodes. Requires a network filesystem or file-share CSI driver (NFS, EFS, Azure Files, etc.).
The image describes different access modes for mounting storage in a computer system, including ReadWriteOnce (RWO), ReadOnlyMany (ROX), and ReadWriteMany (RWX), along with their best usage scenarios and compatible storage types.
Use access modes that match both workload behavior and backend capability — for example, databases typically need RWO; distributed file systems are required for RWX.
The image is a comparison of access modes "ReadWriteOnce," "ReadOnlyMany," and "ReadWriteMany," detailing which nodes can mount them, what they are best for, and their storage types. It advises choosing access modes based on workload needs.
Table: Access modes at a glance

​
Example PVC

A PVC declares size, accessModes, and optionally a storageClassName. Kubernetes will bind an existing PV or ask the StorageClass to provision a PV dynamically. If storageClassName is omitted, the cluster default StorageClass (if configured) will be used. Correct example PVC:
After creation the PVC status should move from Pending to Bound. If the PVC remains Pending inspect it:
Common reasons for Pending:
  • StorageClass name typo or missing StorageClass.
  • Insufficient capacity in the backend.
  • StorageClass uses volumeBindingMode: WaitForFirstConsumer and no pod is scheduled that references the PVC yet.
  • Requested access mode is not supported by available PVs or provisioner.
If a PVC stays Pending, check the StorageClass, backend capacity, and volumeBindingMode. For multi-AZ clusters, prefer WaitForFirstConsumer to ensure volumes are provisioned in the consuming Pod’s zone.

​
StorageClass details

Platform teams define StorageClasses to expose curated storage offerings. Developers reference them by name in PVCs. Example StorageClass:
Table: Key StorageClass fields Notes on reclaim policies:
  • Delete: good for ephemeral or reproducible data where storage lifecycle follows the PVC.
  • Retain: use for critical data that must be preserved after PVC deletion (manual cleanup required).
volumeBindingMode considerations:
  • Immediate may cause volumes to be provisioned in the wrong AZ/zone for multi-AZ clusters.
  • WaitForFirstConsumer ensures volumes are created in the correct topology aligned to where the Pod will run.

​
Choosing storage for workloads

Answer the question “Which storage should I use?” using four criteria: access mode, storage type, reclaim policy, and workload characteristics. Suggested mappings: Name StorageClasses by use case (e.g., fast-ssd, shared-nfs, bulk-hdd) rather than by cloud provider. This keeps the platform portable and makes selection easier for developers.
The image shows a chart for matching workloads to storage types, outlining access modes, storage options, and reclaim policies for different applications like databases, shared files, static content, and batch jobs.

​
Five key takeaways

  • PVCs request storage; PVs provide it. Developers create PVCs; platform teams manage StorageClasses—clear separation of concerns.
  • Access modes dictate sharing semantics. Not every backend supports every mode.
  • StorageClasses abstract provider details; name them by use case to help developers choose the right one.
  • Match workload to storage: databases typically need SSD + Retain; batch jobs can use cheaper disks + Delete.
  • Storage decisions affect both performance and cost—evaluate IO, throughput, durability, and availability when designing StorageClasses.
The image presents a list of five key takeaways about storage in Kubernetes, including topics like PVCs, access modes, StorageClasses, workload matching, and storage decisions.

Watch Video