Observability ohne Instrumentierung: Wie eBPF die Sidecar-Flotte ersetzte

67% der Kubernetes-Teams sind auf eBPF-Observability umgestiegen

Laut der CNCF-Jahresumfrage 2026 nutzen 67% der Kubernetes-Teams jetzt eBPF-basierte Tools fuer mindestens eine Observability-Saeule (Metriken, Traces oder Logs) — gegenueber 29% in 2024 und 41% in 2025.

Der Grund ist einfach: Traditionelle Sidecar-basierte Observability (Envoy-Proxys, OpenTelemetry-Collector-Sidecars, Datadog-Agenten) verbraucht enorme Ressourcen, fuegt jeder Anfrage Latenz hinzu und erfordert Code-Aenderungen. eBPF erledigt alles aus dem Kernel — ohne jede Anwendungsaenderung.

Was ist eBPF und warum ist es wichtig

eBPF (extended Berkeley Packet Filter) ist eine Technologie, die es erlaubt, Sandbox-Programme im Linux-Kernel auszufuehren, ohne den Kernel-Quellcode zu aendern. Urspruenglich fuer Netzwerk-Paketfilterung konzipiert, hat sich eBPF zu einem universellen Kernel-Programmierbarkeits-Framework entwickelt.

Wie es funktioniert

1. Ein kleines Programm schreiben in C oder Rust
2. An einen Kernel-Hook-Point anhaengen — Syscalls, Netzwerk-Events, Tracepoints
3. Der eBPF-Verifier des Kernels prueft das Programm auf Sicherheit
4. Der JIT-Compiler uebersetzt eBPF-Bytecode in native Maschineninstruktionen
5. Das Programm wird ausgefuehrt am Hook-Point mit nahezu nativer Leistung

// Vereinfachtes eBPF-Programm zum Tracen von HTTP-Anfragen
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u16 dport = sk->__sk_common.skc_dport;
    u32 daddr = sk->__sk_common.skc_daddr;
    
    struct event_t event = {
        .pid = pid,
        .dport = ntohs(dport),
        .daddr = daddr,
        .timestamp = bpf_ktime_get_ns(),
    };
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
                          &event, sizeof(event));
    return 0;
}

Warum es fuer Observability wichtig ist

Traditionelle Observability erfordert Instrumentierung. Dieser Ansatz hat drei grundlegende Probleme:

1. Ressourcen-Overhead — Jeder Sidecar verbraucht CPU und Speicher. In einem 500-Pod-Cluster mit Envoy-Sidecars koennen die Sidecars 30-40% der Gesamtressourcen verbrauchen.
2. Abdeckungsluecken — Sie koennen nur beobachten, was Sie instrumentieren.
3. Wartungsaufwand — Jede Sprache und jedes Framework braucht seine eigene Instrumentierungsbibliothek.

eBPF loest alle drei: Es laeuft im Kernel (null Anwendungs-Overhead), sieht alles, was der Kernel sieht (keine Luecken), und funktioniert unabhaengig von der Sprache.

Der eBPF-Observability-Stack 2026

Cilium + Hubble: Netzwerk-Observability

Cilium ist das De-facto-CNI fuer Kubernetes. Hubble bietet:

• L3/L4-Flow-Sichtbarkeit — Jede TCP/UDP-Verbindung zwischen Pods
• L7-Protokoll-Parsing — HTTP, gRPC, Kafka, DNS, PostgreSQL ohne Anwendungsaenderungen
• Netzwerkrichtlinien-Audit — Echtzeit-Sichtbarkeit erlaubter/abgelehnter Traffic
• Service-Abhaengigkeits-Mapping — Automatische Service-Graph-Generierung

Pixie: Application Performance Monitoring

Pixie (CNCF-Sandbox-Projekt) bietet Null-Instrumentierungs-APM:

• Automatisches Protokoll-Tracing — HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS
• Kontinuierliches CPU-Profiling — Flamegraphs aus eBPF-Stack-Traces
• Dynamisches Logging — Trace-Points ohne Redeployment hinzufuegen
• Vollstaendige Request/Response-Erfassung — HTTP-Header, SQL-Queries, gRPC-Payloads

Tetragon: Runtime-Sicherheit und Audit

Tetragon (von Isovalent/Cilium) ist ein eBPF-basiertes Sicherheits-Observability-Tool:

• Prozessausfuehrungs-Tracking — Jedes exec-, fork- und exit-Event
• Dateizugriffs-Monitoring — Lese-, Schreib- und Berechtigungsaenderungen verfolgen
• Netzwerkverbindungs-Audit — Jede ausgehende Verbindung mit Prozesskontext loggen
• Sicherheitsrichtlinien-Durchsetzung — Verdaechtige Aktivitaeten in Echtzeit blockieren

Grafana Beyla: Auto-Instrumentierung

Grafana Beyla ist ein eBPF-basierter Auto-Instrumentierungs-Agent:

• Erkennt HTTP-, gRPC-, SQL- und Redis-Anfragen auf Kernel-Ebene
• Erzeugt OpenTelemetry-Spans mit Trace-Kontext-Propagierung
• Integriert sich mit Grafana Cloud, Tempo, Mimir und jedem OpenTelemetry-Backend

Leistung: Die Zahlen, die zaehlen

Reale Benchmarks aus einem 500-Pod-Produktions-Kubernetes-Cluster:

Speicherverbrauch-Vergleich

Komponente	Sidecar-Ansatz	eBPF-Ansatz	Einsparung
Envoy-Sidecars (500 Pods)	50 GB	0 (Cilium CNI)	50 GB
OTel-Collector-Sidecars (500 Pods)	15 GB	0 (Beyla DaemonSet)	15 GB
Cilium-Agenten (20 Knoten)	N/A	8 GB	-8 GB
Beyla-Agenten (20 Knoten)	N/A	2 GB	-2 GB
Gesamt	75 GB	12 GB	84% Reduktion

CPU-Overhead

Metrik	Sidecar-Ansatz	eBPF-Ansatz
Latenz pro Anfrage	1-5ms	<0.1ms
CPU-Overhead pro Knoten	8-12%	<1%
Tail-Latenz-Auswirkung (p99)	+15-30ms	<1ms

Migrationsleitfaden: Von Sidecars zu eBPF

Phase 1: eBPF-Tools neben Sidecars deployen (Woche 1-2)

• Cilium als CNI installieren
• Hubble fuer Netzwerk-Observability deployen
• Beyla als DaemonSet deployen
• Beide Stacks parallel betreiben

Phase 2: Validieren und Tunen (Woche 3-4)

• Verifizieren, dass eBPF-Tools die gleichen Signale erfassen
• Beylas Protokollerkennung anpassen
• Mirror-Dashboards einrichten

Phase 3: Sidecars schrittweise entfernen (Woche 5-8)

• Mit nicht-kritischen Services beginnen
• Datenqualitaets-Regressionen ueberwachen
• Envoy-Sidecars von Services entfernen, die kein erweitertes Traffic-Management benoetigen

Phase 4: Vollstaendiger eBPF-Stack (Woche 9-12)

• Verbleibende Sidecars entfernen
• Tetragon fuer Runtime-Sicherheit deployen
• Alerting auf eBPF-Signale konsolidieren
• Freigegebene Ressourcen zurueckgewinnen

Haeufig gestellte Fragen

Funktioniert eBPF-Observability mit Nicht-Kubernetes-Workloads?

Ja. eBPF laeuft auf Linux-Kernel-Ebene und funktioniert mit jeder Workload.

Kann eBPF Distributed Tracing ersetzen?

Fuer viele Teams ja. Aber eBPF-Traces sind auf Request/Response-Grenzen beschraenkt.

Was ist mit verschluesseltem Traffic (TLS)?

eBPF-Tools koennen TLS-Traffic tracen, indem sie sich an TLS-Bibliotheksfunktionen anhaengen.

Ist eBPF sicher? Kann ein fehlerhaftes eBPF-Programm den Kernel zum Absturz bringen?

Nein. Der eBPF-Verifier prueft jedes Programm vor dem Laden. Ein fehlerhaftes Programm wird nicht geladen.

Wie handhabt eBPF Hochdurchsatz-Services (100K+ Anfragen/Sekunde)?

Durch In-Kernel-Aggregation und Sampling. eBPF-Programme berechnen Histogramme in Kernel-Maps.