Cilium and eBPF Networking Cheat Sheet

Updated 2026-05-22

Next Topic: Cluster API (CAPI) Cheat Sheet

Cilium is an open-source CNI plugin for Kubernetes that uses eBPF — a Linux kernel technology — to deliver high-performance networking, transparent security enforcement, and deep observability without modifying application code. It matters because it eliminates the overhead of traditional iptables-based networking and the complexity of sidecar proxies, replacing both with kernel-native programs that apply policy and load-balancing directly in the data path. The key mental model: Cilium attaches identity to workloads via labels, not IP addresses, so security policies remain stable even as pod IPs churn continuously across the cluster lifecycle.

What This Cheat Sheet Covers

This topic spans 15 focused tables and 133 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: eBPF Core ConceptsTable 2: Cilium Architecture ComponentsTable 3: Cilium Installation and Key Helm ValuesTable 4: Cilium Identity and Endpoint ModelTable 5: Network Policy (L3/L4) and CRDsTable 6: L7 Policy EnforcementTable 7: kube-proxy Replacement and Load BalancingTable 8: Transparent EncryptionTable 9: Hubble ObservabilityTable 10: Cilium Service Mesh and mTLSTable 11: BGP, LB IPAM, and L2 AnnouncementsTable 12: Cluster Mesh (Multi-Cluster Networking)Table 13: Tetragon Runtime SecurityTable 14: Egress GatewayTable 15: Troubleshooting and Common Pitfalls

Table 1: eBPF Core Concepts

eBPF (extended Berkeley Packet Filter) is the kernel-level technology underpinning everything Cilium does. Understanding its architecture — hooks, maps, the verifier, and JIT compilation — is essential context before working with any Cilium feature.

Concept	Example	Description
eBPF program	`bpf_prog_type = BPF_PROG_TYPE_XDP`	• Sandboxed bytecode loaded into the Linux kernel that runs at a defined hook point • cannot crash or block the kernel
eBPF verifier	`bpftool prog show id 42`	Kernel component that statically validates every eBPF program before loading — ensures no infinite loops, no out-of-bounds memory access, and no unsafe calls.
JIT compiler	`sysctl net.core.bpf_jit_enable=1`	Translates eBPF bytecode into native machine instructions at load time, giving programs performance equivalent to natively compiled kernel code.
eBPF map	`BPF_MAP_TYPE_HASH`, `BPF_MAP_TYPE_LPM_TRIE`	• Shared key-value data structures accessible from both eBPF programs and userspace • the primary mechanism for state and communication
hook point	`kprobe`, `tc ingress/egress`, `XDP`, `cgroup sock`	• Kernel location where an eBPF program is attached • each type gives a different view and control over the system
XDP (eXpress Data Path)	`--set loadBalancer.acceleration=native`	The earliest possible hook in the networking stack — runs inside the NIC driver before any kernel allocation, enabling line-rate packet processing.
kprobe / uprobe	`bpftrace -e 'kprobe:tcp_connect { ... }'`	Dynamic probes that attach eBPF programs to arbitrary kernel (`kprobe`) or user-space (`uprobe`) function entry/exit points.

Table 1: eBPF Core Concepts

Concept	Example	Description
eBPF program	`bpf_prog_type = BPF_PROG_TYPE_XDP`	• Sandboxed bytecode loaded into the Linux kernel that runs at a defined hook point • cannot crash or block the kernel
eBPF verifier	`bpftool prog show id 42`	Kernel component that statically validates every eBPF program before loading — ensures no infinite loops, no out-of-bounds memory access, and no unsafe calls.
JIT compiler	`sysctl net.core.bpf_jit_enable=1`	Translates eBPF bytecode into native machine instructions at load time, giving programs performance equivalent to natively compiled kernel code.
eBPF map	`BPF_MAP_TYPE_HASH`, `BPF_MAP_TYPE_LPM_TRIE`	• Shared key-value data structures accessible from both eBPF programs and userspace • the primary mechanism for state and communication
hook point	`kprobe`, `tc ingress/egress`, `XDP`, `cgroup sock`	• Kernel location where an eBPF program is attached • each type gives a different view and control over the system
XDP (eXpress Data Path)	`--set loadBalancer.acceleration=native`	The earliest possible hook in the networking stack — runs inside the NIC driver before any kernel allocation, enabling line-rate packet processing.
kprobe / uprobe	`bpftrace -e 'kprobe:tcp_connect { ... }'`	Dynamic probes that attach eBPF programs to arbitrary kernel (`kprobe`) or user-space (`uprobe`) function entry/exit points.