eBPF Architecture Diagrams: Kernel Observability, Networking & Security (2026)

eBPF architecture diagrams have become essential documentation for platform engineering and infrastructure teams adopting kernel-level programmability. Extended Berkeley Packet Filter lets you run sandboxed programs in the Linux kernel — without loading kernel modules or rebooting — enabling deep observability, high-performance networking, and granular security enforcement that was previously impossible without modifying kernel source code. Tools like Cilium, Falco, Tetragon, Pixie, and Hubble are built on eBPF and are now standard in production Kubernetes clusters. This guide covers how to diagram eBPF-based systems accurately, from the compilation pipeline to production deployment patterns.

The eBPF execution model: what diagrams must show

eBPF programs follow a specific lifecycle that your architecture diagrams should capture. The pipeline runs top-to-bottom:

• Source code (C / Rust / Go): eBPF programs are written in restricted C (most common), Rust (via Aya framework), or Go (via ebpf-go). Compiled to BPF bytecode using Clang/LLVM with target bpf or bpfel.
• Verifier: The kernel verifier is the safety gate — it statically analyzes the bytecode to ensure no unbounded loops, no out-of-bounds memory access, no use-after-free, and that all paths terminate. Programs that fail verification are rejected before execution. Diagrams should show the verifier as a mandatory checkpoint between user space and kernel attachment.
• JIT compilation: After verification, the kernel JIT-compiles BPF bytecode to native machine code (x86-64, ARM64, s390). Enabled by default on Linux 4.15+. Show this as a transformation step between the verifier and kernel execution.
• Hook attachment: The compiled program is attached to a kernel hook point via the bpf() syscall. Diagrams should show the specific hook type (XDP, TC, kprobe, uprobe, tracepoint, LSM) as the attachment target.
• BPF maps: Shared data structures (hash maps, arrays, ring buffers, perf event arrays) that allow eBPF programs to communicate with each other and with user-space daemons. Maps are the data plane — show them as a separate layer accessible from both kernel and user space.

eBPF hook types and their architecture positions

• XDP (eXpress Data Path): The earliest hook in the network receive path — runs before the kernel network stack allocates an sk_buff. Can drop, redirect, or pass packets at line rate. Used for DDoS mitigation (Facebook's Katran), load balancing (Cilium's kube-proxy replacement), and high-throughput packet filtering. Diagram XDP at the NIC driver layer, before the socket buffer allocation.
• TC (Traffic Control) hooks: Attach to the Linux TC subsystem at the ingress and egress of network devices. More flexible than XDP (sk_buff already exists) but slightly later in the path. Cilium uses TC hooks for pod-level network policy enforcement. Show TC as a layer between the NIC and the kernel network stack.
• kprobes / kretprobes: Dynamic instrumentation of kernel function entry and exit points. Used for deep system call tracing, latency profiling, and security monitoring. Show kprobes attached to specific kernel symbols (e.g., tcp_sendmsg, do_sys_open).
• uprobes / uretprobes: User-space equivalent of kprobes — attach to functions in user-space binaries without modifying them. Used by Pixie and Parca for continuous profiling, and by Falco for user-space threat detection. Show uprobes as attached to process memory space.
• Tracepoints: Stable kernel instrumentation points defined by the kernel team — less likely to break across kernel versions than kprobes. Used for system call auditing (seccomp-bpf), scheduler events, and I/O tracing. Diagram tracepoints as stable interface points in the kernel subsystem layer.
• LSM (Linux Security Module) hooks: eBPF programs attached to Linux security module hooks can enforce security policies with kernel authority — used by Tetragon for runtime security enforcement. Show LSM hooks as a security layer that can deny operations before they complete.

Cilium: eBPF-powered Kubernetes networking

Cilium is the most widely deployed eBPF project in production Kubernetes, replacing kube-proxy and CNI plugins with eBPF programs. Architecture diagrams for Cilium-powered clusters should show several distinct layers:

• Cilium Agent (DaemonSet): Runs on every node. Watches Kubernetes API server for Network Policy, CiliumNetworkPolicy, and Service objects, then compiles and loads the corresponding eBPF programs and populates BPF maps. Show the agent as the control-plane component on each node, with arrows to the kernel BPF map layer.
• eBPF data plane: TC ingress/egress programs attached to each pod's veth interface enforce network policy. XDP programs at the node's physical NIC handle load balancing and service routing — replacing iptables DNAT rules entirely. Show this as a kernel-layer component beneath the pod network namespace.
• BPF maps (shared state): Cilium maintains maps for: service endpoints (replacing kube-proxy iptables), policy verdict cache (per-connection allow/deny), connection tracking, and identity-based security labels. Diagram these maps as the shared data layer between the Cilium agent and the eBPF data plane.
• Hubble (observability): Cilium's observability layer reads from eBPF perf event maps to provide per-connection flow visibility. Hubble Relay aggregates flows across all nodes; Hubble UI visualizes them. Show Hubble as a separate observer process reading from kernel ring buffers.

Prompt examples for eBPF architecture diagrams

eBPF program lifecycle and compilation pipeline

Cilium CNI architecture on Kubernetes

eBPF-based runtime security with Tetragon

eBPF continuous profiling with Parca

eBPF tools by domain

Architecture diagram annotations for eBPF systems

• Linux kernel version requirements: Always annotate the minimum kernel version for each eBPF feature. XDP requires 4.8+; BTF (BPF Type Format, required for CO-RE) requires 5.2+; LSM eBPF requires 5.7+; BPF ring buffer requires 5.8+. These constraints drive your node OS selection.
• Capabilities and security context: eBPF programs loaded by non-root processes require CAP_BPF (Linux 5.8+) or CAP_SYS_ADMIN (older kernels). Diagram the pod security context and which capabilities are granted. Show if privileged mode is required and why.
• BPF map types: Label each BPF map with its type (BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_ARRAY, BPF_MAP_TYPE_RINGBUF, BPF_MAP_TYPE_LRU_HASH) and its size limits. Hash maps have a fixed max_entries — show what happens when maps are full (drops vs. eviction).
• CO-RE (Compile Once, Run Everywhere): Modern eBPF programs using libbpf + BTF can run across kernel versions without recompilation. Annotate whether your eBPF programs are CO-RE-compatible or require matching kernel headers at the target node.
• Sidecar vs. sidecarless: A key architectural choice in 2026 service mesh diagrams. eBPF-based approaches (Cilium Mesh, Istio Ambient Mode + ztunnel) eliminate sidecar proxies; show the difference explicitly with a comparison showing CPU and memory overhead per pod.

Related guides: Kubernetes architecture diagrams, service mesh architecture diagrams, DevSecOps architecture diagrams, zero-trust architecture, and observability architecture diagrams.