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. 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 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. Native routing demands that your network fabric can route the IP addresses of the application containers. 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. Do not 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. 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 README describes Cilium as L7-protocol aware. This is useful for zero-trust segmentation, but it also means more eBPF complexity. The repository's examples/policies/ directory holds example policies. For teams coming from NetworkPolicy-only setups, Cilium's model is more expressive but requires learning new abstractions.

Installation and Configuration

The README points to the Cilium documentation and the Cilium Upgrade Guide. The stable releases are pulled from quay.io, with tags like quay.io/cilium/cilium:v1.20.4. 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. The upgrade guide is referenced for minor releases. 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 older kernels lack some of them. 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. 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. 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, which the README lists among its advanced functionality, is another differentiator. 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. 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.

Frequently asked questions

Official sources

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