Blog
Thoughts on engineering, design, and building great products.
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.
ConfigMap and Secret
Don't bake configuration into the image — pull it into a ConfigMap for ordinary data, a Secret for sensitive data, then inject it via environment variables or files. This article opens Part VI with both: four ways to consume them, one key difference (files auto-update on edit, env doesn't), and the harsh truth that a Secret is only base64, not encrypted — unless you turn it on, which our cluster did in Article 5. Tested for real, dug into etcd.
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.