⚡eBPF
⚡ What is eBPF?
›What is eBPF?
eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that lets you run sandboxed programs inside the kernel at runtime — without modifying kernel source code or loading kernel modules. eBPF programs are verified by the kernel for safety (cannot crash the system, cannot loop infinitely), JIT-compiled to native machine code, and attached to specific kernel hooks that fire when events occur.
Before eBPF: observing or changing kernel behaviour required writing kernel modules — complex C code that could crash the system, required kernel recompiles, and needed server reboots to load. eBPF eliminates all of this. Programs load at runtime in milliseconds with no reboot.
What makes eBPF important for Kubernetes
| Capability | Without eBPF | With eBPF |
|---|---|---|
| Network policy enforcement | iptables rules — O(n) traversal, explodes at thousands of services | eBPF hash maps — O(1) lookup, handles 100K+ services |
| Runtime security monitoring | Userspace agent polling — high overhead, misses events | eBPF kernel probes — instant, near-zero overhead |
| Distributed tracing | Instrument every app with SDK — code changes required | eBPF uprobes — trace any app with zero code changes |
| Load balancing | kube-proxy iptables — one rule per endpoint | Cilium eBPF — replaces kube-proxy entirely |
eBPF hook points — where programs attach
| Hook point | What it observes | Used for |
|---|---|---|
| kprobe/tracepoint | System calls, kernel function calls | Security: detect privilege escalation, file access |
| TC (Traffic Control) | Network packets at ingress/egress | Network policy, load balancing |
| XDP (Express Data Path) | Packets before kernel networking stack | Ultra-fast packet filtering, DDoS mitigation |
| Uprobe | User-space function calls (libc, application code) | Zero-instrumentation app tracing |
⚡ eBPF in Production DevOps
›Three areas where eBPF changes everything
Networking: Cilium replaces kube-proxy. At 500+ services, the performance difference is measurable. The eBPF-based packet routing is O(1) where iptables is O(n).
Security: Tetragon watches kernel-level behaviour and can enforce policy — not just alert but actively block and kill processes. A container trying to read /etc/passwd, spawn a reverse shell, or connect to an unexpected IP gets terminated instantly.
Observability: Pixie and Hubble give you service-level metrics, network flows, and CPU profiles without modifying application code or adding sidecars.
Cilium, Tetragon, Pixie, Hubble — practical usage
🛠️ eBPF Tools Reference
›BCC tools + bpftrace + interview answer
🔐 Cilium — eBPF for Kubernetes Networking
›Cilium — the most important eBPF tool for Kubernetes
Cilium is a Kubernetes CNI (Container Network Interface) plugin that uses eBPF instead of iptables for networking and security. Used by AWS EKS, GKE, and many production clusters.
| Feature | What it does |
|---|---|
| Network Policy | L3/L4/L7 network policies enforced by eBPF — faster than iptables and supports HTTP-level rules |
| Service Load Balancing | Replaces kube-proxy entirely — eBPF maps for O(1) service lookup vs iptables O(n) rules |
| Hubble | Real-time network observability — see every packet flow between pods with zero app changes |
| ClusterMesh | Multi-cluster connectivity — transparent networking between Kubernetes clusters |
| Transparent Encryption | WireGuard or IPSec encryption between nodes — no sidecar needed |
# Install Cilium (replaces kube-proxy) helm repo add cilium https://helm.cilium.io helm install cilium cilium/cilium --namespace kube-system --set kubeProxyReplacement=strict --set hubble.relay.enabled=true --set hubble.ui.enabled=true # Check Cilium status cilium status # Hubble CLI — observe network flows in real time hubble observe --namespace production hubble observe --pod payment-api --protocol http # Example: DNS requests from payment-api pod hubble observe --pod payment-api --verdict FORWARDED --type L7
L7 network policy with Cilium (iptables cannot do this)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: payment-api-policy
spec:
endpointSelector:
matchLabels:
app: payment-api
ingress:
- fromEndpoints:
- matchLabels:
app: order-service
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: POST
path: /api/v1/payment # only allow POST to this path
# GET requests from order-service are DENIED👁️ Hubble, Falco and eBPF Observability
›eBPF for observability — zero instrumentation tracing
| Tool | What it does |
|---|---|
| Pixie (New Relic) | Auto-instruments K8s apps — HTTP, gRPC, SQL traces with zero code changes. Uses eBPF uprobes. |
| Hubble (Cilium) | Network-level observability — see all traffic flows, DNS queries, dropped packets. |
| Falco | Security monitoring — detect abnormal system calls (shell spawned in container, file write in /etc). |
| bpftrace | Ad-hoc kernel tracing — write one-liners to trace any kernel event for debugging. |
| Tetragon (Cilium) | Security enforcement — kill a process immediately if it violates policy using eBPF. |
# Falco — detect shell spawned inside container (possible attack)
# Default rule alerts when a shell process starts in a container
kubectl logs -n falco falco-xyz | grep Warning
# bpftrace — trace all TCP connections in real time
bpftrace -e 'kprobe:tcp_connect { printf("%s -> %s\n", comm, ntop(args->daddr)); }'
# Pixie — auto-trace HTTP requests without code changes
# After installing Pixie agent on K8s:
px run px/http_data -- -start_time="-5m" # last 5 minutes of HTTP traffic🎯 Interview Questions
›eBPF · ARCHITECT
What is eBPF and why is it considered a paradigm shift for observability and security?
eBPF (Extended Berkeley Packet Filter) is a technology that lets you run sandboxed programs inside the Linux kernel safely. Before eBPF, to observe what processes do at kernel level you needed kernel modules (crash risk) or userspace tools like strace (40-50% overhead). eBPF programs are verified by the kernel before execution — no infinite loops, no invalid memory access — so they are safe in production. The paradigm shift: observability without code changes. Traditional APM requires you to add a tracing SDK to every service. With eBPF, deploy one DaemonSet to the cluster and instantly get: every network connection every process makes, every file opened, every system call, CPU profiling — for ALL processes, existing and future. No redeploy needed. For security: Tetragon can KILL a process that violates policy at the kernel level, before it can do damage. For networking: Cilium replaces kube-proxy entirely with eBPF programs that make packet routing 10x faster at scale. Companies like Cloudflare, Meta, Google, and Netflix run eBPF in production at billions of requests per day. In Kubernetes: if you are running Cilium as your CNI, you are already using eBPF even if you do not realise it.
eBPF · ENGINEER
What is Cilium and how does it differ from kube-proxy?
kube-proxy is the traditional Kubernetes component that implements Service routing. It watches the Kubernetes API for Service changes and creates iptables rules. Problem: iptables is a sequential rule list. At 1,000 services you have thousands of iptables rules. At 10,000 services you have tens of thousands. Every packet traverses the full rule list — O(n) complexity. Performance degrades as you scale. Cilium replaces kube-proxy with eBPF programs that implement the same service routing but with hash table lookups — O(1) regardless of how many services exist. Same lookup time at 10 services or 10,000 services. Cilium also provides: network policy enforcement at kernel level (faster than iptables NetworkPolicy), Hubble for network flow visibility, encrypted pod-to-pod communication without a service mesh. The practical difference you feel: at 50-100 services kube-proxy is fine. Beyond 500 services, Cilium shows measurable improvement in network latency and CPU usage on nodes. Large K8s clusters (>500 services) at companies like Adobe, Datadog, and Digital Ocean use Cilium specifically to avoid the kube-proxy scaling problem.
EBPF · ENGINEER
What is eBPF and why is it important for Kubernetes?
eBPF (extended Berkeley Packet Filter) allows running sandboxed programs inside the Linux kernel at runtime. Traditional kernel observability and networking required kernel modules — complex, risky, required reboots. eBPF programs are verified by the kernel (cannot crash it), JIT-compiled to native code, and run with near-zero overhead by hooking into kernel events. For Kubernetes, eBPF matters in three areas: Networking — Cilium uses eBPF instead of iptables for service load balancing and network policy. eBPF maps are O(1) lookups versus iptables O(n) chain traversal. At 10,000+ services, iptables becomes a performance bottleneck. Cilium removes this. Security — Falco uses eBPF to detect malicious behaviour at the kernel level: shell spawned in a container, unexpected file writes to /etc, network connections to suspicious IPs. This catches attacks that evade application-level monitoring. Observability — Pixie and Hubble use eBPF to trace every HTTP request, gRPC call, database query across the entire cluster without any code instrumentation. Zero changes to applications, instant visibility. The practical reason you are asked about it in interviews: Cilium has replaced kube-proxy in EKS and GKE. If you manage production Kubernetes, you are likely running eBPF whether you know it or not.
EBPF · ENGINEER
What is Cilium and how does it differ from standard Kubernetes networking?
Cilium is a Kubernetes CNI plugin and network policy engine built on eBPF. It replaces both the default CNI (Flannel/Calico) and kube-proxy. Standard K8s networking with iptables: kube-proxy maintains iptables rules for every Service. With 1000 services and 10 pods each, that is tens of thousands of iptables rules. Every packet traverses this chain linearly. Cilium with eBPF: services are stored in eBPF hash maps. Lookup is O(1) — constant time regardless of how many services exist. At 10,000 services, iptables takes milliseconds per packet, eBPF takes microseconds. Network policies: standard K8s NetworkPolicy operates at L3/L4 (IP and port). Cilium CiliumNetworkPolicy operates at L7 — you can write rules like "payment-api can call order-service on POST /api/v1/orders but not GET /admin". This is impossible with iptables. Hubble: Cilium includes Hubble, a network observability layer. It records every network flow between pods — source, destination, protocol, HTTP method, status code, latency. You can run hubble observe and see real-time packet flows. Zero application changes needed. Installation: Cilium is now the default CNI in EKS (in newer clusters) and GKE. It can optionally replace kube-proxy entirely (kubeProxyReplacement=strict).
EBPF · PRODUCTION
How does Falco use eBPF for Kubernetes security and what does it detect?
Falco is a runtime security tool that uses eBPF (or a kernel module) to observe system calls and detect anomalous behaviour inside containers. Unlike static security scanners that check images before deployment, Falco monitors running containers and alerts on suspicious activity in real time. How it works: Falco attaches eBPF probes to the kernel system call interface. Every system call (open, execve, connect, write) in every container is observable. Falco rules define what is suspicious. Default rules detect: shell process spawned inside a container (kubectl exec or container escape attempt), sensitive file read (/etc/shadow, /etc/kubernetes/admin.conf), unexpected outbound network connection from a container that should only receive traffic, privilege escalation attempt (setuid, ptrace on another process), write to /etc or other system directories inside a container. Example alert: container payment-api spawned a bash shell. In a well-behaved container, no shell should ever run. This is an indicator of compromise. Falco sends alerts to stdout, Slack, PagerDuty, Elasticsearch. Integration with Kubernetes: Falco enriches alerts with K8s context (namespace, pod name, deployment, labels). You know immediately which workload is affected. Response: combine with Tetragon (also Cilium) for immediate enforcement — Tetragon can kill a process the moment it violates a policy, not just alert.
Continue Learning