Most Kubernetes tutorials commit the same sin: they describe the zoo without explaining evolution. Here's a Pod, here's a Node, here's a Cluster — arrange them in a diagram, move on. For an experienced sysadmin who already knows what a load balancer is, this is useless. This post exists because its author got tired of having opinions without evidence and decided to fix that. The core argument is that Kubernetes' real value collapses to two concepts. First, control loops — the pattern where a controller continuously observes a variable (queue depth, latency, node health) and adjusts a different variable (replica count, cluster membership) to converge on a desired state. This isn't Kubernetes-specific; it's borrowed directly from control theory. But naming it clearly, with concrete examples like autoscaling on P90 latency, makes the abstraction load-bearing instead of decorative. Second, Services — and here the post gets genuinely useful. Rather than saying 'Services provide stable access to Pods,' the author maps the mechanism to its classical equivalent: N nodes running Keepalived plus NGINX with dynamic backends, plus CNAME records for the virtual IP. Every Node receives netfilter rules for every Service via kube-proxy, which means all Nodes act as load balancers with no single point of failure. The author then follows the implications: rule count scales with Service count (problematic for iptables' linear evaluation), traffic gets forwarded multiple times in some scenarios, and DNS cache invalidation becomes a non-issue because misbehaving clients that skip re-resolution still work. The workload management section walks the abstraction ladder cleanly: raw Pod (manual, fragile), ReplicaSet (self-healing count but frozen config), Deployment (rolling updates via ReplicaSet rotation). Each rung exists because the previous one has a specific, named limitation. This is how technical writing should work — motivation before mechanism. Storage gets the same treatment, from ephemeral volumes (useful for sidecar log shipping, not much else) through PersistentVolumes (driver-agnostic but that means you can't rely on driver-specific features like atomic renames) to StatefulSets with their ordered deployment semantics. The author flags a genuine oddity: StatefulSets create and delete Pods in a fixed ascending/descending order based on the assumption that lower-numbered instances are 'more stable,' which doesn't survive contact with the reality that a crashy Pod keeps its number. What makes this post work is the author's willingness to say 'I still don't understand this' and 'this seems weird.' The StatefulSet ordering question is left open. The operational question of how to inspect a PersistentVolume when your container has no shell is flagged without a clean answer. These are the seams where real understanding lives, and most tutorials plaster over them. The post cuts off before a completed scorecard, which is its main structural weakness — you're promised a verdict and don't quite get it. But the 80% that exists is the best kind of technical writing: an experienced practitioner thinking in public, translating new concepts through the lens of systems they already understand, and being honest about where their understanding stops.
