Blog
Thoughts on engineering, design, and building great products.
Leader Election, Addons, and Node Autoscaling
The cluster runs three control planes, but controller-manager and scheduler keep only one instance active at a time — if all three acted, they'd step on each other. This article looks at the mechanism that prevents that: leader election via a Lease, and proves real failover by taking the leader down and watching another controller win the lock. Then it closes Part XIII with addons and node autoscaling — adding and removing machines by load.
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.
Resource Requests/Limits and Autoscaling (HPA)
Every pod has to state how much CPU/RAM it wants — that's how the scheduler places pods correctly and the cluster doesn't fall over because one pod hogs everything. Once declared, the HorizontalPodAutoscaler raises and lowers replica count with load. This article generates real load and watches HPA scale from 1 up to many pods.