Why every greenfield cluster we ship in 2026 starts with Cilium and Hubble, and what we are seeing at migration.
iptables was a miracle in 2005 and a problem by 2015. The linear rule-list evaluation did not scale to the size of a modern Kubernetes service set, kube-proxy’s iptables mode made troubleshooting feel like an archaeology dig, and every packet you wanted to observe required a tap, a mirror, or a sidecar.
eBPF rewires the assumptions. Programs run in the kernel at the right hook points (XDP, tc, cgroup, socket), maps carry state, and you can answer the “what just happened to this packet” question without tcpdumping a node. Cilium is the most mature eBPF networking and security stack on Kubernetes and it is now our default.
The short list of reasons: identity-based network policy that does not depend on pod IPs, L7 visibility without a sidecar, gateway API with an implementation that actually keeps up with the spec, Hubble for flow logs your SRE team will actually read, and the Gateway/Ingress consolidation story that removes a layer from the stack.
Migration is never free, and it is not the wholesale policy rewrite it sounds like. Cilium implements the standard Kubernetes NetworkPolicy API directly, so existing NetworkPolicy objects keep working once it is your CNI. CiliumNetworkPolicy is an additive CRD you reach for when you want what plain NetworkPolicy cannot express — L7 rules, DNS/FQDN-aware egress, entity-based policy — not a conversion every rule has to go through. The real work is kube-proxy replacement rolled out carefully per node pool, and observability on both sides during the cutover. The steady state is strictly simpler than what it replaces, and the operational win shows up in fewer 2am pages and shorter mean-time-to-understanding on incidents.
Every greenfield cluster we ship starts here now. For brownfield we plan the migration as its own engagement.