Cilium

Cilium is a networking, security, and observability solution for containerized environments, built on an eBPF dataplane. It's aimed at platform engineers and SRE teams running Kubernetes who need a CNI that scales, enforces identity-based policy, and gives deep visibility into traffic without relying on sidecar proxies or iptables. Cilium is a CNCF Graduated project, maintained by an active community and used across cloud and on-prem clusters.

Key features

• eBPF dataplane: dynamically inserts eBPF bytecode into the Linux kernel at network IO, socket, and tracepoint layers, avoiding the overhead of traditional iptables-based networking.
• CNI plugin: supports overlay networking (VXLAN, Geneve) and native routing modes, plus automated route learning via L2 discovery or BGP.
• kube-proxy replacement: implements distributed load balancing in eBPF hash tables for both east-west (socket-level rewriting) and north-south (XDP, DSR, Maglev) traffic.
• Cluster Mesh: connects multiple Kubernetes clusters with global service discovery and a unified identity model for cross-cluster policy enforcement.
• Identity-based network policy: enforces L3-L7 rules tied to workload identity rather than IP address, including DNS-based (FQDN) policies and L7-aware rules (HTTP methods, paths, gRPC calls, header matching).
• Service mesh capabilities: mutual authentication via IPSec or WireGuard, L7 policy enforcement, and a Gateway API-compliant data plane for ingress and traffic routing.
• Hubble observability: real-time service maps, flow visibility with identity/label metadata, DNS-aware filtering, and drop-reason diagnostics, integrated with Prometheus and Grafana.

Ideal use cases

Cilium fits teams running Kubernetes at meaningful scale who need a CNI that replaces kube-proxy, enforces fine-grained network policy, or connects multiple clusters. It's a good match if you need L7-aware policy (blocking specific HTTP methods or paths), DNS-based egress control to third-party domains, or a Gateway API data plane without adding sidecar proxies. Multi-cloud or hybrid deployments benefit from Cluster Mesh's cross-cluster service discovery and consistent identity model.

It's less of a fit for small, single-node clusters or environments where a minimal CNI (like a basic flannel or bridge setup) already meets networking needs and you have no requirement for policy enforcement, observability, or service mesh features. Running eBPF-based networking also requires a compatible Linux kernel, so environments with very old kernels or restricted kernel access (some managed sandboxes) may hit limitations. Teams unfamiliar with eBPF or kernel-level networking should budget time to learn the operational model before rolling it out to production.

Installation

Cilium is typically installed on an existing Kubernetes cluster. The README points to the official documentation for the current install flow, which generally follows this pattern:

1. Install the Cilium CLI:

curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz

2. Install Cilium into your cluster:

cilium install

3. Verify the installation:

cilium status
cilium connectivity test

Container images are published for AMD64 and AArch64 architectures under tags like quay.io/cilium/cilium:v1.20.1, with the main branch published daily as quay.io/cilium/cilium-ci:latest for testing (not for production use). Each image includes a Software Bill of Materials in SPDX format. For production deployments, minor versions are maintained for the last three releases; check the Cilium Upgrade Guide before moving between minor versions. Full install instructions, including options for different routing modes and kube-proxy replacement, are in the official docs at docs.cilium.io.