Blog
Thoughts on engineering, design, and building great products.
Ingress: Getting HTTP In From Outside (With Cilium)
NetworkPolicy handles pod-to-pod traffic inside the cluster. This article opens the cluster edge to HTTP from outside, routing by host and path to the right Service — using Cilium's built-in Ingress controller, no extra software to install. Just as important as the mechanics is a real decision: Ingress NGINX was retired in March 2026 and the Ingress API is frozen, so we pick a maintained controller and watch how Cilium translates an Ingress into Envoy config running on eBPF.
NetworkPolicy: A Firewall By Label
By default every pod in the cluster talks freely with every other — flat and open. This article uses NetworkPolicy to lock it down: deny all ingress to a pod, then allow only the right labels through, tested for real on a Cilium cluster. And because the cluster runs eBPF, we get to watch Hubble print DROPPED/FORWARDED verdicts per packet, with Cilium identity proving policy attaches to labels, not IPs.
Migrating to kube-proxy-less Cilium
Theory's done, now for real: replace Part I's kube-proxy + bridge with eBPF-based Cilium 1.19, remove kube-proxy entirely, enable Hubble. This article traces each migration step on a live cluster — install Cilium, disable kube-proxy, confirm Services still work with not a single kube-proxy iptables rule left — plus four real traps a self-built cluster hits (providerID, topology labels, IMDS hop limit, hostNetwork) and how to clear them.
Cilium and eBPF: why replace kube-proxy
In Part I we built pod networking with kube-proxy iptables and a hand-rolled bridge — enough to run, but iptables grows linearly with the number of Services. Part X upgrades: replace both kube-proxy and the bridge with eBPF-based Cilium. This article is the theory — what eBPF is, why it's faster than iptables, what Cilium does differently at the datapath — looking straight at the 74 iptables rules currently running to see what we're about to drop.
Wiring Up Pod Networking by Hand: CNI bridge and VPC Routes
The previous theory article laid the groundwork; this one does the assembly. We write the CNI bridge + host-local config for each worker, add routes in the VPC route table so pod-to-pod across nodes works, then watch the two nodes finally flip to Ready. At the end we create two real pods on two different nodes and ping between them — each pod gets an IP from its node's range, and packets cross nodes without NAT.
The Kubernetes Network Model
Before wiring up pod networking in the next article, you need to understand what kind of network model Kubernetes demands: one IP per pod, every pod talking directly with no NAT. This article walks through the model's four foundational requirements, the four kinds of in-cluster communication, why pod-to-pod across nodes is the hard part, the two families of solutions (overlay and native routing), and where CNI fits — laying the groundwork for the hands-on wiring next.
Ingress: Routing HTTP Into the Cluster
NodePort gives each service a weird port — no good when you have many services. Ingress is a single HTTP entry point, routing by domain and path to the right service, with TLS. This article: enable minikube's ingress addon, write an Ingress rule, and test Host-based routing.