Blog
Thoughts on engineering, design, and building great products.
The New Storage of v1.36
Part IX built PV/PVC, StorageClass, EBS CSI, snapshots. v1.36 adds three storage pieces that just went stable, and a from-scratch cluster can try two of them right away: mounting an OCI image's content as a volume, and changing the IOPS/throughput of an EBS volume in use without recreating it — watching the change apply straight to AWS. The third, VolumeGroupSnapshot, is a different lesson: a feature being GA in Kubernetes doesn't mean every CSI driver can do it.
VolumeSnapshot and CSI snapshot
We have persistent volumes now — how do we back them up? VolumeSnapshot takes a point-in-time snapshot of a PVC's contents — and with EBS CSI, it creates a real EBS snapshot on AWS. This article closes Part IX: install the snapshot controller, snapshot a PVC, restore a new PVC from that snapshot — with a hard-won lesson on why the first restore came out an empty file, and why you must sync before snapshotting.
StorageClass, dynamic provisioning, and EBS CSI
In Article 42 the admin had to create the PV by hand first. Nobody does that at real scale. StorageClass + CSI driver flip it around: the user creates only a PVC, the system spawns the PV — and even calls AWS to create a real EBS volume. This article installs the real EBS CSI driver (with IAM for the nodes), traces every link of who-calls-who from PVC to the moment an EBS volume is born, then deletes the PVC and watches the volume disappear.
PersistentVolume and PersistentVolumeClaim
The volumes in Article 41 die with the pod. To make data outlive the pod, Kubernetes splits it in two: PersistentVolume is the real storage (admin creates), PersistentVolumeClaim is the storage request (user creates) — and a control loop binds them. This article traces who-creates-what, who-binds-what: admin builds a PV, user requests a PVC, the controller binds both ways, a pod uses the claim, delete the pod and data survives, delete the claim and the PV goes Released.
Volumes: ephemeral, hostPath, and projected
Files in a container vanish on restart, and two containers in one pod don't see each other's files. Volumes solve both. This article opens Part IX (storage) with volumes attached straight to a pod: emptyDir (a scratch area shared within the pod), hostPath (borrow a node directory), and projected (combine configMap/secret/downwardAPI/token into one place) — each tested for real, making clear which lives with the container, the pod, or the node.
StatefulSet: stable identity and order
A Deployment treats every pod as an anonymous school of fish — any one is interchangeable. But a database, message queue, or etcd is not: each node needs a fixed identity and its own data. The StatefulSet exists for exactly that need. This article digs into its four guarantees — stable names, per-pod DNS via a headless service, ordered creation and deletion — verifying each on a real cluster, and leaving the volume part for the Storage section.
Storage: Volumes, PV, PVC and StorageClass
Data inside a pod evaporates with the pod — no good for a database or user files. Kubernetes separates the 'storage request' (PVC) from the 'real disk' (PV), with StorageClass for dynamic provisioning. This article proves data outlives the pod with a delete-then-recreate experiment.