Cilium: An eBPF Dataplane for Kubernetes Networking, Security, and Observability

What Cilium Solves and Who Needs It

Cilium addresses a specific pain: Kubernetes clusters that outgrow the default kube-proxy and iptables-based networking. The README states that Cilium implements distributed load balancing for pod-to-pod and pod-to-external traffic, and can fully replace kube-proxy using efficient hash tables in eBPF. This matters for operators running large clusters where iptables rules become slow and unwieldy. The target user is a platform engineer or SRE who manages Kubernetes at scale and needs a single dataplane that also enforces security policies. Cilium is not a simple plugin; it is a comprehensive networking, observability, and security solution. It is a CNCF graduated project, which signals governance maturity, though that alone should not drive a decision. The core value is the decoupling of security identity from IP addresses, which is rare in traditional CNIs.

The eBPF Mechanism and Data Flow

Cilium's foundation is eBPF, a Linux kernel technology that allows dynamic insertion of bytecode at integration points like network IO, application sockets, and tracepoints. The README explains that this bytecode implements security, networking, and visibility logic. In practice, Cilium attaches eBPF programs to network hooks, so packets are processed in the kernel without userspace round trips. The data flow starts when a pod sends traffic; the eBPF program inspects the packet, maps the destination IP to a security identity, and applies policy. This identity-based model is decoupled from network addressing, so policies survive IP changes. For load balancing, Cilium uses hash tables in eBPF to distribute traffic, which is why it can replace kube-proxy. The architecture is a set of agents running on each node, which compile and load eBPF programs. The README mentions support for both native routing and overlay modes, which affects how packets traverse the network. This mechanism is not trivial to debug; engineers need to understand eBPF maps and kernel internals.

Deployment Modes: Overlay vs Native Routing

The README lists two primary deployment options. Overlay networking uses VXLAN or Geneve encapsulation to create a virtual network across hosts. The only requirement is IP connectivity between hosts, which most infrastructures already have. This mode is forgiving because it does not require changes to the underlying network. Native routing mode uses the regular Linux routing table, meaning the network must be capable of routing container IPs directly. This integrates with cloud routers, routing daemons, and IPv6-native infrastructure. The choice between these modes is a real trade-off. Overlay adds encapsulation overhead, though eBPF mitigates some of it. Native routing offers lower latency but demands that your network fabric can handle pod CIDRs. The README also mentions flexible routing options like L2 neighbor discovery for shared layer 2 domains and BGP for layer 3. For an engineer, this means you must decide early which mode fits your physical network. The documentation does not give performance numbers, so you cannot assume one is faster without testing.

Security and Policy Model

Cilium's security model is identity-based, not address-based. The README states it can enforce network policies on L3-L7. This is a departure from traditional CNIs that filter by IP or CIDR. Each pod gets a security identity derived from labels, and eBPF programs enforce policies based on that identity. This allows policies to survive pod rescheduling and IP changes, which is a practical advantage in dynamic clusters. The L7 awareness means Cilium can inspect HTTP, gRPC, or Kafka protocols, though the README does not list specific protocols. This is useful for zero-trust segmentation, but it also means more eBPF complexity. The security model is tightly coupled to the dataplane, so policy changes require updating eBPF programs, which can have a performance impact. The README does not detail how policies are written, but it implies a Kubernetes-native approach. For teams coming from NetworkPolicy-only setups, Cilium's model is more expressive but requires learning new abstractions.

Installation and Configuration

The README does not include a quickstart command, but it points to the Cilium documentation for installation. Based on the repository layout, installation typically uses Helm or the cilium CLI. The stable releases are pulled from quay.io, with tags like quay.io/cilium/cilium:v1.20.0. The README lists actively maintained branches: v1.20, v1.19, and v1.18. For development, there are daily CI images from the main branch, but the README explicitly warns these are not for production. Configuration keys are not in the README, but the upgrade guide is referenced for minor releases. A typical install would involve setting the datapath mode (overlay or native), the routing mode, and the kube-proxy replacement option. You also need to configure the cluster pool for pod CIDRs. The SBOM is included from version 1.13.0, so you can inspect dependencies in SPDX format. The images support AMD64 and AArch64, which is relevant for ARM-based clusters.

Limitations and Failure Modes

Cilium is not a fit for every environment. The most obvious limitation is kernel dependency. eBPF features vary by kernel version, and the README does not specify minimum versions, but it is a known constraint that older kernels lack required features. If you run Kubernetes on nodes with old or custom kernels, Cilium may not function. Another failure mode is the complexity of debugging. When eBPF programs misbehave, you need tools like bpftool and kernel logs, which are not familiar to all teams. The README also notes that the main branch images are for testing only, so using them in production is unsupported. The overlay mode adds encapsulation overhead, which can be a problem for latency-sensitive workloads. The L7 policy inspection can also become a bottleneck if not tuned. Finally, the project maintains only the last three minor releases; older versions are EOL. This means you must upgrade frequently to stay supported, which is an operational cost.

Alternatives and How They Differ

The main alternative is Calico, which also provides networking and policy for Kubernetes. Calico typically uses iptables or eBPF, but its default mode is not eBPF-based. Cilium's approach is to put everything in eBPF from the start, whereas Calico offers a more traditional routing and iptables model. This difference matters: Cilium's identity-based policy is not tied to IP addresses, while Calico often uses IP-based policies unless you enable its eBPF mode. Another alternative is Flannel, which is simpler and only provides overlay networking without security or observability. Flannel does not replace kube-proxy, so you would need a separate component. Cilium's integrated service mesh is another differentiator, but the README does not detail it. For teams that want minimal complexity, Flannel is easier, but it lacks Cilium's features. For teams that need advanced policy and scale, Cilium's eBPF approach is more direct, but it requires more expertise.

Maintenance, Upgrades, and Licensing

Cilium is licensed under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. The README states that stable releases are maintained for the last three minor versions, and older ones are EOL. This means you must plan upgrades at least every few months to stay on a supported branch. The upgrade guide is referenced for new minor releases, which suggests that breaking changes are possible. The project publishes SBOMs in SPDX format starting with version 1.13.0, which helps with vulnerability scanning and supply chain audits. The release cadence shown in the recent releases includes patch updates across three branches, indicating active maintenance. However, the README does not mention a formal deprecation policy beyond the three-version window. For an engineer, this means budgeting time for regular upgrades and testing. The images are distributed on quay.io, so you need to trust that registry or mirror it. The development images are rebuilt daily, but they are not for production.

Editorial conclusion

Adopt Cilium if you run Kubernetes and need a single dataplane for networking, policy, and observability with eBPF efficiency, especially at scale where kube-proxy becomes a bottleneck. Skip it if your team lacks kernel or eBPF expertise, or if your infrastructure cannot meet kernel version requirements. Before adopting, verify your kernel supports required eBPF features, test the upgrade path from your current CNI, and confirm that your service mesh needs are covered by Cilium's mesh features or that you will integrate an external mesh. Also, check the SBOM for supply chain compliance and review the upgrade guide for breaking changes between minor versions.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes