Blog
Thoughts on engineering, design, and building great products.
Device Plugins and Extended Resources
Pods can request CPU and memory, but what about a GPU, a high-speed NIC, or an FPGA? A device plugin is how a node advertises hardware beyond CPU/memory as an extended resource for pods to request and the scheduler to divvy up. This article stands up a real device plugin, captures the full gRPC flow it uses to register with kubelet and advertise devices, watches kubelet call Allocate when a pod runs, then uses the underlying mechanism to see the scheduler split it like CPU.
Node-pressure eviction
The last three articles were about placing pods. This one is about evicting them — but not preemption (scheduler, for priority) or the OOM kill (kernel, for exceeding a limit). This is the kubelet proactively killing pods when a node truly runs out of RAM or disk, by its own thresholds and ranking. This article creates real memory pressure on a worker by hand, then watches the kubelet evict the right hungriest pod — with an eviction message that says exactly why.
Priority and preemption
A node is full and an important pod was just created. Does it hang Pending behind the junk pods, or does it get to kick out a less important pod to grab the spot? PriorityClass assigns a priority level; preemption lets a high-priority pod evict low-priority pods when needed. This article fills the cluster with low-priority pods, then drops in a high-priority one — watch it kick out the victim and take the spot, exactly the PostFilter step Article 34 called 'not helpful'.
Topology spread, pod overhead, and scheduling readiness
Anti-affinity is rigid: one pod per node, anything extra hangs. Topology spread is softer — it spreads pods evenly by maxSkew while still allowing several pods per node. This article digs into three finer scheduling mechanisms: topologySpreadConstraints (flexible spreading), pod overhead (extra resource accounting for the sandbox runtime), and schedulingGates (hold a pod back from scheduling). All three tested for real on the cluster.
Affinity, taints, and tolerations
The scheduler picks a node on its own, but often you need to intervene: this pod must be on an SSD node, two replicas shouldn't share a machine, that node is for one team. This article digs into three tools for steering the scheduler — nodeAffinity (pull a pod toward labeled nodes), podAntiAffinity (push pods apart), taint/toleration (a node pushes pods away unless tolerated). Tested for real: a pod stuck on affinity, a third with nowhere to go, one evicted by NoExecute.
The scheduler and the scheduling framework
Every pod we create has someone quietly picking a node for it — that's kube-scheduler, the thing we stood up in Article 8 but never looked at closely. This article opens Part VII by digging into exactly how it picks: filter out nodes that don't fit, score the remaining nodes, then bind. We test for real a pod stuck because no node has room, a pod that gets a node, and watch scoring pile pods onto the less-loaded node — not a naive round-robin.
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.