Blog
Thoughts on engineering, design, and building great products.
Migrating to kube-proxy-less Cilium
Theory's done, now for real: replace Part I's kube-proxy + bridge with eBPF-based Cilium 1.19, remove kube-proxy entirely, enable Hubble. This article traces each migration step on a live cluster — install Cilium, disable kube-proxy, confirm Services still work with not a single kube-proxy iptables rule left — plus four real traps a self-built cluster hits (providerID, topology labels, IMDS hop limit, hostNetwork) and how to clear them.
Cilium and eBPF: why replace kube-proxy
In Part I we built pod networking with kube-proxy iptables and a hand-rolled bridge — enough to run, but iptables grows linearly with the number of Services. Part X upgrades: replace both kube-proxy and the bridge with eBPF-based Cilium. This article is the theory — what eBPF is, why it's faster than iptables, what Cilium does differently at the datapath — looking straight at the 74 iptables rules currently running to see what we're about to drop.
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.