Cilium: eBPF-Based Networking, Security, and Observability

TL;DR: cilium/cilium is the Go, Apache-2.0, CNCF-graduated project that uses eBPF to deliver networking, security, and observability for Kubernetes. 25,277 stars on GitHub, homepage at https://cilium.io.

What it is

cilium/cilium describes itself as “eBPF-based Networking, Security, and Observability.” The repository is written in Go, has 25,277 stars, and is published under the Apache-2.0 license. The homepage is https://cilium.io. The GitHub topic list covers the full Kubernetes stack: bpf, cncf, cni, containers, ebpf, k8s, kernel, kubernetes, kubernetes-networking, loadbalancing, monitoring, networking, observability, security, troubleshooting, xdp. The cncf topic confirms the project’s graduated status inside the Cloud Native Computing Foundation.

What it does well

Cilium replaces the older iptables-based Kubernetes networking stack with one that runs in the kernel via eBPF, and the project has spent the years since CNCF graduation turning that performance gap into a complete networking platform.

• CNI by default. It is a Kubernetes CNI plugin, and the topic list flags both cni and kubernetes-networking, which means it can be dropped in as the cluster-wide pod network without bolting other components on.
• Security policy at L3-L7. Cilium enforces network policies with identity-aware rules rather than IP-only rules, which matters once a cluster grows past a handful of namespaces.
• Service mesh without sidecars. The same eBPF datapath powers load balancing and east-west traffic, so you can run a mesh shape without injecting Envoy into every pod.
• Observability built in. Hubble, the observability layer, surfaces flow logs and DNS at the kernel level — monitoring and troubleshooting are explicit topics — which is useful when something is on fire at 3 a.m.
• Kernel-level primitives. bpf, ebpf, xdp, and kernel are all in the topic list, which signals the project keeps close to the kernel surfaces it depends on rather than abstracting them away.

How to try it

The quickest path is the cilium-cli install, which works on any conformant Kubernetes cluster.

# Install the CLI
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin

# Install into a cluster
cilium install --version 1.16.0
cilium status --wait

For a local kind or minikube cluster, the cilium install step is enough to get a working CNI with Hubble observability turned on.

When it fits, and when it doesn’t

Cilium fits any production Kubernetes cluster that has outgrown the default networking stack, that needs identity-aware network policy, or that wants the same kernel datapath to cover service mesh, observability, and CNI in one go. It is less attractive if you are running a small single-node cluster where the simpler CNIs are still sufficient, or if your kernel version is too old to support the eBPF features Cilium depends on. The 25,277 star count and CNCF graduation are the relevant signals here — the project has settled into the default-CNI role across a meaningful slice of the Kubernetes install base.

Source and Accuracy Notes

• Project page: https://github.com/cilium/cilium
• Source repository: cilium/cilium (verified via GitHub API html_url)
• License: Apache-2.0
• Stars at time of writing: 25,277
• Language: Go
• Homepage: https://cilium.io