Kubernetes networking has a reputation for being one of the most confusing parts of the platform. Pods get IPs, services get virtual IPs, kube-proxy does something with iptables, and somehow CNI plugins glue it all together. Most tutorials drop you straight into kubectl apply and hope the abstractions click. They rarely do.

This post takes the opposite approach: it strips Kubernetes away entirely and rebuilds the networking story from Linux primitives upward. Based on the title and URL slug, the author appears to walk through the foundational pieces that Kubernetes itself depends on:

• Linux network namespaces — the kernel feature that gives each pod its own isolated networking stack
• veth pairs and bridges — how two namespaces actually talk to each other
• iptables and NAT — the mechanism behind kube-proxy's service routing
• Routing tables — how packets find their way between nodes

Once those pieces are concrete — something you can poke at with ip netns commands on a single Linux box — the Kubernetes abstractions stop feeling like magic. A pod is just a network namespace. A service IP is just an iptables DNAT rule. A CNI plugin is just a program that wires veth pairs into a bridge or overlay. The CKA exam material suddenly reads like documentation instead of incantation.

This bottom-up framing is genuinely valuable for a technical audience because it converts memorized facts into mental models. Engineers who learn Kubernetes networking this way can debug ClusterIP weirdness by running iptables -t nat -L, troubleshoot pod-to-pod failures by inspecting routing tables, and reason about why their CNI choice (Calico vs. Cilium vs. Flannel) actually matters — instead of cargo-culting YAML.

It's also the kind of post that ages well. Linux networking primitives have been stable for two decades. Kubernetes APIs churn, but the namespace/veth/iptables substrate underneath does not. Learn it once, and every container runtime — Docker, containerd, Podman, Kubernetes — becomes legible.

The post sat at 1 point with zero comments, likely because "Kubernetes networking" headlines are a dime a dozen on HN. This one earns the click by inverting the usual pedagogy.