Durable Storage with PVCs
Give a workload storage that survives a restart: claim a PersistentVolume and mount it, and understand why the claim only binds once a Pod needs it.
Your mission
A container's filesystem is ephemeral — restart the Pod and anything it wrote is gone. For data that must survive (a database, uploads, a cache you don't want to rebuild), you need a PersistentVolume: storage whose lifecycle is independent of any Pod.
You rarely create the volume directly. Instead you write a PersistentVolumeClaim — a request for "so much storage, with these access modes" — and a StorageClass provisions a matching volume on demand. The Pod then mounts the claim.
One behaviour trips people up: with the common WaitForFirstConsumer binding
mode, a PVC stays Pending until a Pod actually mounts it. That's not a bug —
the scheduler waits to place the volume near the Pod. The claim binds the moment a
workload uses it.
In this lab you create a claim, then mount it into a Deployment and watch it bind.
Useful aliases
k is aliased to kubectl and completion is configured. The jumpbox also has
k9s, jq and yq.