Blog
Thoughts on engineering, design, and building great products.
In-place Pod Resize
Throughout the series, changing a container's resources meant recreating the pod. In-place pod resize breaks that: adjust a running pod's CPU/memory without a restart, via the resize subresource. This article resizes a real pod, then inspects cgroup v2 on the node changing in place with restartCount still 0 — the 'no disruption' counterpart to Article 40's vertical scaling — and two constraints: you can't change QoS, and why memory needs its own resizePolicy.
Node Allocatable: the resources a pod actually gets
Article 22 looked at requests/limits from the pod side. This one flips to the node side: a 2-vCPU machine doesn't let pods use all 2 vCPUs. Kubernetes carves off a slice for system daemons, one for Kubernetes daemons, and a buffer against running out of RAM — what's left is Allocatable, the part the scheduler divides up. We dig into the formula, read Capacity vs Allocatable on a real node, then add a reservation by hand and watch Allocatable drop by exactly that many Ki.
Requests, limits, QoS and the Downward API
Declaring requests and limits for a container isn't just about picking numbers. requests guide the scheduler, limits are kernel-enforced fences — CPU gets throttled, exceeding memory is an OOM kill. From those numbers Kubernetes sorts pods into three QoS classes that decide who gets killed first when the node runs out of RAM. This article tests all three QoS classes for real, an OOMKilled, and the Downward API for a pod to read information about itself.
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.