Kubernetes Storage: From Ephemeral to Persistent

Kubernetes has more than one way to persist data. These four challenges walk the full stack from the simplest ephemeral volume to manually provisioned persistent storage.

Each challenge builds on the previous one. By the end you will understand how storage is provisioned, bound, and recovered - and the difference between letting a provisioner handle it versus managing PVs by hand.

Ephemeral (challenge 1): emptyDir - sharing data between containers, volume lifecycle, memory-backed storage, and pod eviction.

Dynamic provisioning (challenge 2): StorageClass, the DefaultStorageClass admission controller, switching the cluster default, and inspecting where local-path stores volumes on the node.

Static provisioning (challenge 3): generic match, label selector, bidirectional claimRef binding, and local PVs with WaitForFirstConsumer.

Reclaim policies (challenge 4): Delete and Retain policies, recovering a Released PV by patching claimRef, and recovering data by creating a new PV pointing to the same directory.

An emptyDir volume is created when a pod is assigned to a node and deleted when the pod is removed. All containers in the pod share it. This challenge covers sharing data between containers, surviving container crashes, init container patterns, memory-backed storage, and pod eviction from ephemeral-storage limits.

A StorageClass names a provisioner and carries provisioning settings. When a PVC omits storageClassName, the DefaultStorageClass admission controller injects the cluster default. This challenge covers how that injection works, how to explicitly name a class, how to switch the cluster default, and where local-path actually stores volume data on the node.

In static provisioning an administrator creates PVs by hand and a PVC binds to an existing one. This challenge covers the three binding patterns - generic class match, label selector, and bidirectional claimRef - plus local PVs with WaitForFirstConsumer for topology-aware node-pinned storage.

Every PV has a reclaim policy that determines what happens when its PVC is deleted. Delete removes the PV and its storage. Retain keeps the PV and its data in place in a Released state. This challenge covers both policies and shows two recovery patterns for a Retained PV - patching claimRef and creating a new PV pointing to the same directory.