Blog
Thoughts on engineering, design, and building great products.
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.
Priority and preemption
A node is full and an important pod was just created. Does it hang Pending behind the junk pods, or does it get to kick out a less important pod to grab the spot? PriorityClass assigns a priority level; preemption lets a high-priority pod evict low-priority pods when needed. This article fills the cluster with low-priority pods, then drops in a high-priority one — watch it kick out the victim and take the spot, exactly the PostFilter step Article 34 called 'not helpful'.
Topology spread, pod overhead, and scheduling readiness
Anti-affinity is rigid: one pod per node, anything extra hangs. Topology spread is softer — it spreads pods evenly by maxSkew while still allowing several pods per node. This article digs into three finer scheduling mechanisms: topologySpreadConstraints (flexible spreading), pod overhead (extra resource accounting for the sandbox runtime), and schedulingGates (hold a pod back from scheduling). All three tested for real on the cluster.
Affinity, taints, and tolerations
The scheduler picks a node on its own, but often you need to intervene: this pod must be on an SSD node, two replicas shouldn't share a machine, that node is for one team. This article digs into three tools for steering the scheduler — nodeAffinity (pull a pod toward labeled nodes), podAntiAffinity (push pods apart), taint/toleration (a node pushes pods away unless tolerated). Tested for real: a pod stuck on affinity, a third with nowhere to go, one evicted by NoExecute.
The scheduler and the scheduling framework
Every pod we create has someone quietly picking a node for it — that's kube-scheduler, the thing we stood up in Article 8 but never looked at closely. This article opens Part VII by digging into exactly how it picks: filter out nodes that don't fit, score the remaining nodes, then bind. We test for real a pod stuck because no node has room, a pod that gets a node, and watch scoring pile pods onto the less-loaded node — not a naive round-robin.
LimitRange and ResourceQuota
When many teams share one cluster, nothing stops team A from creating 10,000 pods or asking for 64Gi RAM for a single container — unless you set rules. LimitRange sets defaults and min/max for each pod in a namespace; ResourceQuota caps the total resources and object count the whole namespace can use. This article closes Part VI with both: testing for real the default-injection, the over-max 403, and the fourth pod blocked by quota.