Blog
Thoughts on engineering, design, and building great products.
Object management, recommended labels, and storage version
For the same Deployment, we have three ways to create and edit it — type a command directly, create -f a file, or apply a whole directory — and mixing them invites bugs. This article closes Part V with those three object-management techniques (plus why apply differs from create -f), the recommended app.kubernetes.io/* label set so tools speak the same language, and storage version — digging into etcd to see which API version an object is actually stored in.
Finalizers, ownerReferences and garbage collection
Every time we deleted a Deployment, the pods and ReplicaSet vanished with it — we called that garbage collection without dissecting it. This article digs into the mechanism: ownerReferences link parent and child, the garbage collector auto-cleans children when the parent is gone (background, foreground, or orphan), and finalizers block deletion until cleanup is done. All three tested for real — including an object stuck in Terminating because of a finalizer.
Labels, selectors, namespaces and annotations
We've typed -l app=web dozens of times without stopping to ask how it works. This article opens Part V with the toolkit for organizing and querying objects: labels to tag and select (equality and set-based), annotations to attach non-identifying metadata, namespaces to isolate, and field selectors to filter by built-in fields. Each kind of selector is tested for real on a basket of labeled pods.
Job, CronJob and TTL
Every controller so far runs forever — Deployment, StatefulSet, DaemonSet keep pods alive indefinitely. The Job inverts this: it runs one task until done, then stops, perfect for migrations, backups, batch work. This article closes Part IV with the Job (completions, parallelism, backoffLimit), the CronJob that runs on a cron schedule, and TTL that auto-cleans finished Jobs — testing each on a real cluster, including catching a CronJob fire exactly on the minute boundary.
DaemonSet: one pod per node
A Deployment manages N replicas placed anywhere; a StatefulSet manages N pods with identity. The DaemonSet is the third model: it doesn't count replicas but guarantees exactly one pod per node — add a node and a pod appears, remove a node and it vanishes. The mold for log agents, CNI, node exporters. This article digs into how it pins a pod to each node, why its pods run even on a not-ready node, and how to limit it to a group of nodes — tested on two real workers.
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.