Traditionelles Monitoring funktioniert wie ein Röntgenbild — Sie sehen ein Bild, müssen aber raten, was innen passiert. eBPF ist wie ein Endoskop: Sie gehen direkt in den Betriebssystemkernel und beobachten jedes Paket, jeden Syscall und jede Speicherallokation in Echtzeit. Ohne Agenten. Ohne Code-Instrumentierung. Ohne Neustarts.

Was ist eBPF und warum Sie es kennen sollten¶

eBPF (extended Berkeley Packet Filter) ist eine Technologie, die direkt in den Linux-Kernel eingebaut ist und das Ausführen von sandboxed Programmen im Kernel Space ermöglicht. Ursprünglich entstand sie zum Filtern von Netzwerkpaketen, heute deckt sie Observability, Sicherheit und Networking ab.

Kerneigenschaft: eBPF-Programme hängen sich an Hook Points im Kernel an — an Syscalls, Netzwerk-Events, Scheduler-Events, Dateisystem-Operationen. Der Kernel verifiziert sie vor der Ausführung (keine Endlosschleifen, kein Zugriff auf verbotenen Speicher), sodass sie auch in Produktion sicher sind.

Warum ist das revolutionär? Traditionelles Monitoring erfordert entweder Agenten (Overhead, Wartung) oder Anwendungsinstrumentierung (Codeänderungen, Vendor Lock-in). eBPF braucht beides nicht — es beobachtet das System von innerhalb des Kernels, transparent für Anwendungen.

Drei Säulen der eBPF-Observability¶

1. Netzwerk-Observability¶

eBPF sieht jedes Paket, das den Netzwerk-Stack passiert. Im Gegensatz zu traditionellen Tools (tcpdump, Wireshark) geschieht dies effizient — Filterung und Aggregation direkt im Kernel, nur relevante Daten werden in den User Space gesendet.

• Cilium Hubble: Volle L3/L4/L7-Sichtbarkeit in Kubernetes — wer kommuniziert mit wem, Latenz, Fehlerrate, DNS-Abfragen
• TCP-Retransmissions: Paketverlusterkennung ohne pcap — Identifizierung problematischer Nodes im Cluster
• Service Map: Automatische Abhängigkeitskarte zwischen Microservices, ohne Codeänderungen

2. Application Performance¶

eBPF kann die Anwendungsperformance ohne APM-Agenten überwachen. Mittels uprobe/uretprobe hängt es sich an User-Space-Funktionen an und misst Latenz, Allokationen und I/O-Operationen.

eBPF — Observability direkt aus dem Linux-Kernel¶

mittels bpftrace — ohne Codeänderungen!¶

bpftrace -e ‘uprobe:/usr/bin/myapp:net/http.(*ServeMux).ServeHTTP {

@start[tid] = nsecs;

}

uretprobe:/usr/bin/myapp:net/http.(*ServeMux).ServeHTTP /

@start[tid]/ {

@latency_us = hist((nsecs - @start[tid]) / 1000);

delete(@start[tid]);

}’

Dieser Ansatz hat einen Overhead von unter 2 % — Größenordnungen weniger als traditionelle APM-Agenten (typischerweise 5–15 %).

3. Security Monitoring¶

eBPF ist die Grundlage der neuen Generation von Runtime-Security-Tools. Statt Firewall-Regeln überwacht es das Prozessverhalten in Echtzeit:

• Tetragon (Cilium): Kernel-Level Security Observability — Überwachung von Syscalls, Dateizugriffen, Netzwerkverbindungen auf Prozessebene
• Falco + eBPF-Treiber: Runtime-Bedrohungserkennung mit eBPF-Backend statt Kernel-Modul
• Anomalieerkennung: Ein Prozess hat eine Shell im Container gestartet? Sich mit einem ungewöhnlichen Port verbunden? eBPF erkennt es sofort

eBPF in Kubernetes — Wo es am meisten Sinn macht¶

Kubernetes ist die ideale Umgebung für eBPF. Eine dynamische Umgebung mit Tausenden von Containern, ephemeren Pods, Service Mesh — traditionelles Monitoring kann nicht mithalten. eBPF löst mehrere schmerzhafte Probleme:

• Ersatz für kube-proxy: Cilium mit eBPF ersetzt iptables — bessere Performance, bessere Sichtbarkeit, Skalierung auf Tausende von Services
• Service Mesh ohne Sidecars: Cilium Service Mesh implementiert mTLS und L7-Policies direkt im Kernel — keine Envoy-Sidecar-Container, geringerer Overhead
• Network Policies: Native Durchsetzung im Kernel, nicht über iptables-Ketten
• Pod-Level-Metriken: CPU, Speicher, Netzwerkverkehr — direkt im Kernel pro cgroup aggregiert

Ökosystem der Tools 2025¶

Das Ökosystem rund um eBPF hat 2025 Produktionsqualität erreicht:

• Cilium 1.16+: CNI-Plugin für Kubernetes mit voller eBPF-Observability und Service Mesh
• Grafana Beyla: Auto-Instrumentierung von HTTP/gRPC-Services mittels eBPF — Zero-Code-Observability
• Pixie (CNCF): Kubernetes-Observability-Plattform — Auto-Telemetrie ohne Agenten
• bpftrace: High-Level-Tracing-Sprache für Ad-hoc-Debugging — „awk für Kernel-Tracing”
• Tetragon: Security Observability und Runtime Enforcement von den Machern von Cilium
• Kepler: Kubernetes-Energiemonitoring mittels eBPF — Verfolgung des Energieverbrauchs pro Pod

Praktisches Deployment — Wie man anfängt¶

eBPF erfordert Linux-Kernel 5.10+ (idealerweise 5.15+ oder 6.x für alle Funktionen). Die meisten Cloud-Anbieter (AKS, EKS, GKE) bieten bereits Nodes mit ausreichend neuem Kernel an.

1. Beginnen Sie mit Cilium: Ersetzen Sie das Standard-CNI (Calico/Flannel) durch Cilium — Sie erhalten Netzwerk-Observability „kostenlos”
2. Aktivieren Sie Hubble: Dashboard zur Visualisierung des Netzwerkverkehrs — Service Map, Latenz, DNS
3. Fügen Sie Grafana Beyla hinzu: Auto-Instrumentierung für RED-Metriken (Rate, Errors, Duration) ohne Codeänderungen
4. Security mit Tetragon: Runtime-Policies — Erkennung verdächtigen Verhaltens in Containern
5. Ad-hoc-Debugging: Bringen Sie dem Team bpftrace bei für schnelle Diagnose von Produktionsproblemen

Worauf zu achten ist¶

eBPF ist keine Silberkugel. Einige Dinge, die vorab wissenswert sind:

• Kernel-Version: Ältere Distributionen (RHEL 7, CentOS 7) haben keine ausreichende Unterstützung — planen Sie ein Upgrade
• BTF (BPF Type Format): Für CO-RE (Compile Once, Run Everywhere) benötigen Sie einen Kernel mit BTF — prüfen Sie vor dem Deployment
• Windows: eBPF für Windows existiert, liegt aber deutlich hinter Linux zurück — primär eine Linux-Technologie
• Lernkurve: Das Schreiben eigener eBPF-Programme erfordert Kenntnisse in C und Kernel-Internals — für die meisten Teams reichen fertige Tools
• Privilegien: eBPF-Programme benötigen CAP_BPF Capability — Sicherheitsimplikationen in Multi-Tenant-Umgebungen

Zusammenfassung¶

eBPF ist die wichtigste Infrastrukturtechnologie des Jahrzehnts. 2025 ist sie von der experimentellen Phase in den Mainstream-Produktionsbetrieb übergegangen. Für Kubernetes-Cluster ist Cilium praktisch der Standard. Für Observability bietet sie einen agentenlosen Ansatz mit minimalem Overhead.

CORE SYSTEMS implementiert eBPF-basierte Observability und Security-Monitoring für Kubernetes und Bare-Metal-Infrastruktur.