Blog
Thoughts on engineering, design, and building great products.
StatefulSet: stable identity and order
A Deployment treats every pod as an anonymous school of fish — any one is interchangeable. But a database, message queue, or etcd is not: each node needs a fixed identity and its own data. The StatefulSet exists for exactly that need. This article digs into its four guarantees — stable names, per-pod DNS via a headless service, ordered creation and deletion — verifying each on a real cluster, and leaving the volume part for the Storage section.
Deployment: rollout and rollback
So far we've only created bare Pods. No one runs production that way — pods are handed to a Deployment, which manages them through a middle layer: the ReplicaSet. This article opens Part IV by digging into that mechanism: changing the image spawns a new ReplicaSet, a rolling update scales it up while scaling the old one down, and the old ReplicaSet is kept at 0 so rollback is one command. Tested step by step on a real cluster, tracing Pod → ReplicaSet → Deployment.
Disruptions and the PodDisruptionBudget
Pods vanish in two very different ways: involuntary (the node dies, runs out of RAM — no one can stop it) and voluntary (draining a node for maintenance, upgrade — deliberate). A PodDisruptionBudget only guards the second kind: it tells the cluster not to take down too many replicas at once. This article distinguishes the two kinds of disruption then verifies a PDB with the real Eviction API — seeing an evict blocked with HTTP 429 firsthand.
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.
Ephemeral containers and kubectl debug
Good production containers often have no shell — the leaner a distroless image, the fewer debugging tools, so kubectl exec is stuck. This article uses ephemeral containers: slip a tooling container temporarily into a running pod without restarting it or modifying its image. It digs into the semantics per the docs, then verifies all three modes of kubectl debug — attach to a running pod, copy the pod, and debug a node directly — on a real cluster.
Probes: liveness, readiness and startup
Article 18 left the Ready condition unexplained. Behind it sits the probe — how the kubelet asks a container three different questions: are you alive, are you ready for traffic, have you finished starting. This article separates the three kinds of probe per the docs, then verifies each with real pods: liveness kills and restarts, readiness removes the pod from a Service's endpoints, startup disables the other two until the app has time to start.
Init Containers and Sidecar Containers
A pod isn't just its main container. An init container runs preparation work to completion before handing off to the app; a sidecar container runs alongside the app for the lifetime of the pod. This article distinguishes the two, digs into the precise semantics from the docs — startup order, error handling, shutdown order — and verifies it with real pods on a v1.36 cluster.