Cilium¶

eBPF-powered CNI plugin providing networking, security, and observability for Kubernetes and cloud-native workloads.

Overview¶

Cilium is the leading eBPF-based CNI for Kubernetes. It replaces traditional iptables-based networking with kernel-level eBPF programs, delivering 30–40% higher throughput, built-in L7 policy enforcement, a sidecar-free service mesh, and deep observability via Hubble. It is a CNCF Graduated project and the default CNI in many managed Kubernetes offerings.

Key Facts¶

Attribute	Detail
Repository	github.com/cilium/cilium
Stars	~22k+ ⭐
Latest Version	v1.19.2 (March 20, 2026); v1.20 in development
Language	Go, C (eBPF programs)
License	Apache 2.0
Governance	CNCF Graduated
Kernel Requirement	Linux ≥5.8 (recommended ≥5.10)

Evaluation¶

Pros	Cons
eBPF: 30–40% faster than iptables	Requires Linux kernel ≥5.8
Hubble: deep network observability	Higher complexity than Flannel
Tetragon: kernel-level runtime security	Requires CAP_BPF / CAP_SYS_ADMIN
Sidecar-free service mesh	Steeper learning curve
L3/L4/L7 network policies	Resource overhead (eBPF maps)
Socket-level load balancing	Migration from iptables-based CNIs non-trivial
CNCF Graduated, massive community

Architecture¶

flowchart TB
    subgraph Node["Kubernetes Node"]
        subgraph Kernel["Linux Kernel"]
            eBPF["eBPF Programs\n(TC, XDP, socket)"]
            Maps["eBPF Maps\n(hash tables, LRU)"]
        end
        Agent["Cilium Agent\n(DaemonSet)"]
        Hubble["Hubble\n(observability)"]
    end

    subgraph CP["Control Plane"]
        Operator["Cilium Operator"]
        ETCD_C["Cilium etcd\nor CRDs"]
    end

    Agent -->|"loads"| eBPF
    Agent -->|"updates"| Maps
    Agent -->|"watches"| CP
    eBPF -->|"flow events"| Hubble

    style Kernel fill:#f9a825,color:#000
    style CP fill:#7b1fa2,color:#fff

Key Features¶

Feature	Detail
eBPF data plane	O(1) hash lookups replace linear iptables chains
Hubble	Flow logs, service maps, DNS visibility, Prometheus metrics
Tetragon	Runtime security: process, file, network monitoring at kernel level
Network Policy	L3/L4 + L7 (HTTP, gRPC, Kafka, DNS)
Service mesh	Sidecar-free, per-node Envoy or kernel-only
Cluster mesh	Multi-cluster connectivity with global services
BGP	Native BGP peering for bare-metal load balancing
Bandwidth manager	EDT-based rate limiting in eBPF
Encryption	WireGuard or IPsec between nodes
Gateway API	Native Kubernetes Gateway API support

Notes¶

Sources¶

Cilium Docs — official documentation
eBPF & XDP Reference — kernel data plane
Hubble — observability pipeline
Tetragon — runtime security enforcement
GitHub — source code
Cilium Blog — release announcements
CNCF Graduated — governance

Questions¶

Open¶

What is the real-world memory overhead of ztunnel in Cilium's mesh mode vs Istio ambient ztunnel?

Answered¶

Q: Does Cilium work with kernel < 5.8? -- No. eBPF features require >= 5.8.
Q: Is Cilium a service mesh? -- Yes, it includes sidecar-free mesh via Envoy + eBPF.
Q: How does Cilium handle eBPF map memory pressure at 10,000+ pod scale? -- BPF maps are pre-allocated in kernel memory. At 10,000+ pods, the endpoint map and connection tracking map can consume significant memory (multiple GB depending on configuration). Cilium provides tuning parameters via Helm values such as bpf.mapMaxSize and bpf.ctMapEntries to control map sizes. The identity-based model helps -- instead of per-IP entries, pods sharing labels share a single identity, reducing map entries. For very large clusters, consider increasing node memory, tuning CT map timeouts, and enabling connection tracking garbage collection.
Q: What is the migration path from kube-proxy to Cilium kube-proxy replacement? -- Cilium supports a per-node gradual migration. The steps are: (1) Install Cilium with kubeProxyReplacement=false (hybrid mode) alongside existing kube-proxy. (2) Label a node with io.cilium.migration/kube-proxy-replacement=true and cordon it. (3) Patch the kube-proxy DaemonSet with node affinity to exclude labeled nodes. (4) Delete the Cilium pod on that node to reload with kube-proxy replacement enabled. (5) Verify with cilium config get kube-proxy-replacement. (6) Uncordon the node. (7) Repeat for all nodes. (8) Set the global config kube-proxy-replacement true, delete the kube-proxy DaemonSet, and remove migration labels. See architecture for kube-proxy replacement details.