Cilium: eBPF Networking, Security and Observability

What Cilium is

Cilium is a networking, observability and security solution for Kubernetes built on an eBPF dataplane. It gives a cluster a flat Layer 3 network that can span multiple clusters in either native routing or overlay mode, enforces network policy from L3 up to L7 using identities instead of IP addresses, and can fully replace kube-proxy with load balancing implemented in eBPF hash tables.

The foundation is eBPF, a Linux kernel technology that lets programs be inserted into the kernel at hook points such as network I/O, application sockets and tracepoints. Cilium uses those hooks to implement networking, security and visibility logic without per-packet trips through user space. The project is a CNCF graduated project, and it targets platform engineers and cluster operators who need a CNI that also covers load balancing, encryption, multi-cluster connectivity and flow-level observability.

How it works

A Cilium deployment is made of a few cooperating components, as described in the component overview:

• Agent (cilium-agent) runs on every node. It takes configuration from Kubernetes or APIs, watches for workloads starting and stopping, and manages the eBPF programs the kernel uses to control traffic into and out of those containers.
• Operator handles cluster-wide duties once per cluster. It is not in the forwarding or policy path, so the cluster keeps working if it is briefly unavailable, although IP allocation for new workloads can be delayed.
• CNI plugin (cilium-cni) is invoked by Kubernetes when a pod is scheduled or terminated and asks the local agent to set up the datapath.
• Hubble provides observability: a server embedded in each agent, a relay (hubble-relay) for cluster-wide visibility, a CLI and a UI that draws service dependency maps.
• Data store: state between agents is propagated through Kubernetes custom resource definitions by default.

The security model is the key idea. Instead of filtering on source IPs and ports, which would require updating firewalls on every server whenever a container starts anywhere, Cilium assigns a security identity to groups of containers that share the same policies. That identity travels with the packets and is validated on the receiving node. Cilium also probes the running kernel and uses newer eBPF features as they become available.

Two command-line tools are easy to confuse. The cilium CLI is installed on your workstation and talks to the cluster through kubeconfig to install, manage and troubleshoot Cilium. The in-agent debug client, cilium-dbg, ships with the agent on each node, talks to that agent's REST API and can inspect eBPF maps directly. eBPF programs themselves are checked by an in-kernel verifier for safety and compiled by a JIT to native instructions, which is where the dataplane gets its efficiency.

Key features

• CNI networking: overlay networking with VXLAN or Geneve, native routing using the host routing table, and automated route learning and advertisement through L2 neighbour discovery or BGP.
• kube-proxy replacement: east-west load balancing rewrites connections at the socket level on connect(), avoiding per-packet NAT.
• North-south load balancing: XDP for high-throughput paths, layer 4 load balancing with Direct Server Return and Maglev consistent hashing.
• Cluster Mesh: global service discovery and failover across clusters, with identity-based policy that holds across all of them.
• Network policy: L3/L4 rules on labels, protocols and ports; DNS-based rules for FQDNs and wildcards such as *.trusted.com; L7 rules by HTTP method, path, gRPC call or headers; plus CIDR rules for external IPs.
• Service mesh: transparent encryption with IPsec, WireGuard or ztunnel, L7-aware enforcement, and a Gateway API compliant data plane for ingress and traffic splitting.
• Observability: Hubble service maps and flow visibility with identity and label metadata, Prometheus and Grafana integration, and drop reasons that explain why traffic was denied.
• Supply chain: since 1.13.0 every image ships a Software Bill of Materials in SPDX format.

Getting started

The quick installation guide uses the Cilium CLI, which installs Cilium, inspects its state and toggles features such as Cluster Mesh and Hubble. The generic requirements are a Kubernetes cluster configured to use CNI and a Linux kernel of 5.10 or newer. On Linux, the docs install the CLI like this:

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

Then cilium install with a --version flag deploys Cilium into the cluster your kubectl context points to; the installer tries to pick the best configuration for the detected Kubernetes distribution. Validate the result:

cilium status --wait
cilium connectivity test

For a local trial, the docs show minikube bringing up a single-node cluster prepared for Cilium, noting that it may not install the latest Cilium version:

minikube start --cni=cilium

Managed clusters need a little preparation: the GKE and EKS examples taint nodes with node.cilium.io/agent-not-ready so application pods wait until Cilium is ready, and AKS clusters are created with no CNI plugin (BYOCNI).

Use cases

• Default CNI for production clusters: one component for pod networking, service load balancing and network policy, replacing kube-proxy.
• Zero-trust segmentation: identity-based and L7 policies, for example allowing only GET requests to /public/.* or restricting egress to named third-party APIs.
• Multi-cluster and hybrid cloud: Cluster Mesh for cross-cluster service discovery and failover with consistent policy.
• Encryption in transit: IPsec or WireGuard between workloads without sidecars.
• Network troubleshooting: Hubble flow logs and drop reasons to find out why a connection or DNS lookup failed.

How it compares

The README frames Cilium against typical container firewalls that filter on IP addresses and ports, and against traditional proxy-based service meshes, which it describes as carrying more cost and complexity than its approach. Against the standard kube-proxy, Cilium replaces iptables-style service handling with eBPF hash tables. Other CNIs such as Calico or Flannel occupy the same slot; Cilium's distinguishing points, by its own description, are the eBPF dataplane, identity-based L3-L7 policy and built-in Hubble observability. Evaluate against your kernel versions and cloud provider support before switching.

Things to know before adopting

• Kernel requirements: Linux 5.10 or newer for the generic install; features adapt to what the kernel supports.
• Release support window: the community maintains the last three minor versions, currently v1.20, v1.19 and v1.18; older minors are EOL. Images are published for AMD64 and AArch64.
• Scale guidance: the quick install suits most clusters, but the docs point environments over 500 nodes, or specific datapath modes, to the advanced guides.
• Unmanaged pods: cilium install restarts pods that were running before Cilium so they get Cilium networking; plan for that on existing clusters.
• Licensing: user-space components are Apache-2.0, while BPF code templates are dual-licensed under GPL-2.0 and BSD-2-Clause at your option.
• Development images: cilium-ci images built from main and pre-releases such as v1.21.0-pre.3 are not for production.

Project activity

As of October 2026 the cilium/cilium repository has about 25,700 stars. It was created in December 2015, is written in Go and is licensed under Apache-2.0 (with GPL-2.0/BSD-2-Clause BPF templates). The latest stable release is v1.20.4, published on October 23, 2026, alongside patch releases v1.19.10 and v1.18.16. Community channels include Slack, weekly developer meetings and the eCHO livestream. Source is at github.com/cilium/cilium and documentation at docs.cilium.io.