Cilium's eBPF networking becomes the default path across GKE, AKS and EKS

The big three converge on one CNI

Cilium, the eBPF-based Container Network Interface, has shifted from a niche choice to the networking backbone of the major managed Kubernetes platforms. According to a dev.to analysis published in October, Google Cloud now ships Cilium as the standard CNI in GKE Autopilot, Microsoft Azure positions it as the preferred advanced networking option for AKS, and Amazon recommends it for demanding EKS scenarios. For a layer of the stack where Calico, Flannel, Weave and Cilium long coexisted as matters of taste, that level of agreement across the three hyperscalers is unusual.

What eBPF changes under the hood

Cilium's core idea is to replace iptables-driven packet processing with small programs loaded directly into the Linux kernel. The dev.to piece explains the mechanics: classic CNIs rely on iptables chains that grow linearly as services and rules are added, producing measurable latency spikes once a cluster reaches thousands of rules. Cilium instead uses eBPF maps that offer constant-time lookup, so network performance stops degrading as cluster size grows.

The analysis cites 2026 benchmark figures of up to 28.5 Gbit/s throughput in pod-to-service traffic, a P99 latency of 0.8 ms, and roughly half the CPU consumption of iptables-based alternatives. There is a constraint, however: the approach requires Linux 5.4 or newer, with 5.15+ recommended for production. Clusters running older node images cannot adopt it and remain dependent on Calico or Flannel.

Layer 7 policy without a service mesh sidecar

Beyond raw performance, the analysis points to policy enforcement as Cilium's real differentiator against Calico and Flannel. Standard Kubernetes NetworkPolicies operate at the connection level — allowing TCP on port 8080, say — while CiliumNetworkPolicy resources can express rules at the HTTP method and path level: permit GET requests to a products endpoint from the frontend, block DELETE calls to an admin path. Because the inspection happens close to the kernel, no Envoy sidecar needs to run alongside each pod.

The piece also makes a compliance argument: for regimes such as SOC 2 or ISO 27001, path-level rules become testable artifacts that can be verified directly in a CI/CD pipeline, rather than retrospectively patched firewall configuration.

Hubble turns network flows into first-class data

Cilium's integrated observability layer, Hubble, taps into the same eBPF hooks used for policy enforcement. The result, per the dev.to analysis, is full visibility into network flows without agents, sidecars or sampling: every connection is logged with source and destination pod, protocol, policy verdict and byte counters. Operationally, that means a command like hubble observe --verdict DROPPED surfaces rejected connections directly, instead of an engineer correlating inconsistent application logs across twenty microservices. Hubble also exposes a native OpenMetrics endpoint, so existing Prometheus and Grafana stacks can consume the data without new tooling.

Where Calico and Istio still fit

The author's 2026 decision matrix is straightforward: new clusters should default to Cilium, Calico remains the right choice where older kernels or BGP requirements in bare-metal environments apply, and Istio only earns its place where genuinely complex traffic management — canary deployments, dynamic traffic mirroring — is needed. A common pattern described is Cilium providing the base network layer with Istio layered on top only where the overhead is justified.

For teams still on Calico or Flannel, the piece notes that migration to Cilium is documented through the official Helm chart and can proceed node by node without production downtime, though the learning curve is real. Cilium is a CNCF graduated project.

Why it matters

Two shifts are worth noting. First, Kubernetes networking is consolidating around a single eBPF-based implementation endorsed by all three major cloud providers — which means tooling, skills and troubleshooting practices built around iptables-based CNIs gradually lose relevance. Second, capabilities that previously required a service mesh, such as L7 policy and flow-level observability, now live in the kernel, allowing many organisations to shrink or skip a mesh deployment entirely.

The caveats: this is a single community analysis rather than vendor documentation, and the benchmark figures are the author's citations rather than independently verified results. Kernel version requirements also make adoption partly a node-upgrade question. Still, with Google, Microsoft and Amazon all pointing in the same direction, platform teams running older CNIs have a clear signal to start planning a migration path.