Blog
Thoughts on engineering, design, and building great products.
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.
Vertical Pod Autoscaler and resource managers
HPA adds pods as load rises. VPA does the opposite: keep the pod count fixed but dial in the exact CPU/RAM each pod needs — no more setting requests at random and then wasting or starving. This article installs VPA (an add-on, like Metrics Server), lets it observe a real workload and produce a recommendation, then crosses to the node side: CPU Manager static policy pins whole CPU cores to a Guaranteed pod — tested for real, watching a pod get exactly one exclusive CPU.
Metrics Server and HorizontalPodAutoscaler
Part VIII changes direction: instead of killing pods under load, we add pods. But to autoscale by CPU, the cluster has to know how much CPU each pod uses — and our hand-built cluster has nobody measuring it yet. This article installs the first add-on, Metrics Server, hits the exact KTHW trap (control plane can't talk to a pod) then fixes it, then stands up an HPA and burns real CPU to watch it multiply pods from 1 to 4.
Node-pressure eviction
The last three articles were about placing pods. This one is about evicting them — but not preemption (scheduler, for priority) or the OOM kill (kernel, for exceeding a limit). This is the kubelet proactively killing pods when a node truly runs out of RAM or disk, by its own thresholds and ranking. This article creates real memory pressure on a worker by hand, then watches the kubelet evict the right hungriest pod — with an eviction message that says exactly why.