Kubernetes notes from production experience — pod lifecycle, scheduling, autoscaling, traffic routing, and the production hygiene that separates a cluster that works from one that keeps working under pressure.
6 articles · updated regularly
A Java service kept getting OOMKilled by Kubernetes while its own heap graphs sat calmly at 60% with gigabytes to spare. The JVM was healthy by every metric it reported. The kernel killed it anyway, because the memory the JVM does not count, off-heap buffers, thread stacks, and metaspace, pushed the whole process past a container limit the JVM was never looking at.
Every rollout sprayed a few hundred 502s for about ten seconds, then went quiet. The app was healthy, the new pods were fine, and nobody could agree on what was broken. The bug was in the gap between Kubernetes deleting a pod and the load balancer noticing.
Readiness gates traffic, liveness restarts containers, startup protects slow boots — and wiring them up the same way is how a slow dependency turns into a restart loop. The differences that matter.
Get requests and limits wrong and you either waste half your cluster or get pods OOM-killed and CPU-throttled at the worst moment. A practical guide to setting them.
The defaults work fine in dev. They will betray you in prod. Here's the checklist I run on every cluster before I let it hold real traffic.
If you've ever stared at a 200-line YAML and wondered who hurt the people who designed this — this is for you. The mental model that makes K8s actually click, in plain language.