Abstract

The sidecar model that Istio, Linkerd, and Consul Connect popularized in the late 2010s brought mutual TLS, traffic policy, and telemetry to Kubernetes workloads without requiring application changes. The tradeoff was resource overhead: every pod ran a proxy container consuming additional CPU and memory, and every request crossed an extra network hop through localhost. Cilium’s eBPF-native service mesh, now generally available in its 1.15 and 1.16 releases, achieves the same goals by encoding policy and observability directly into the Linux kernel datapath, eliminating the sidecar entirely.

How eBPF Replaces the Proxy

Traditional sidecar proxies intercept traffic by configuring iptables rules that redirect packets through a user-space process like Envoy. This works but adds latency proportional to the number of context switches between kernel and user space. Cilium uses eBPF programs attached to cgroup and socket hooks to enforce L7 policy and collect metrics at the point where the kernel hands off packets to the socket, before they leave the process namespace. The result is that mutual TLS termination, HTTP path-based routing, and per-service latency histograms are computed in the kernel without spawning an extra process per pod. On kernel 5.10 and later, Cilium can enforce WireGuard-encrypted pod-to-pod traffic transparently at the node level, which is the sidecar-free equivalent of mesh mTLS.

Network Policy Depth

Kubernetes’ built-in NetworkPolicy resource operates at L3 and L4, allowing rules based on IP CIDR blocks, namespaces, and ports. Cilium extends this with CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy resources that add L7 awareness. A policy can permit HTTP GET requests to /api/products while denying POST to the same service, or restrict Kafka consumer groups to specific topic prefixes, without writing a line of application code. These policies are enforced in eBPF maps, so there is no control-plane latency for rule lookups at request time. Policy changes propagate to nodes via the Cilium operator and take effect in milliseconds once the eBPF map is updated.

Observability Without Sidecars

Hubble is Cilium’s built-in observability layer. It uses eBPF ring buffers to capture network flow events at the kernel level, aggregating them into a Prometheus-compatible metrics endpoint and a gRPC flow API. The hubble observe CLI gives operators a real-time stream of service-to-service traffic with HTTP method, status code, and DNS resolution details, equivalent to what you would get from querying an Envoy access log. Hubble Relay aggregates flows from all nodes into a single query endpoint, and Hubble UI provides a graphical service map that updates in near-real time. Because the data comes from eBPF rather than a proxy, there is no blind spot for traffic that bypasses the sidecar, which was a known limitation in environments where some workloads ran with sidecar injection disabled.

Migration Considerations

Teams migrating from Istio to Cilium mesh face two main challenges. First, Istio’s VirtualService and DestinationRule abstractions have no direct equivalent in Cilium; traffic management policy must be rewritten as CiliumNetworkPolicy or delegated to a Gateway API implementation such as Envoy Gateway running at the ingress layer. Second, the Cilium requirement for kernel 5.10 or later rules out older node images, particularly in managed Kubernetes services that default to Amazon Linux 2 or Ubuntu 20.04 kernels. Both constraints are known and trackable, and for teams already running modern kernels, the latency reduction and resource savings are typically significant enough to justify the migration effort.