eBPF NetFlow Traffic-Überwachung Bare-Metal K8s

eBPF und NetFlow für Traffic-Monitoring: Von Bare Metal bis Kubernetes

Ein System auf Basis von eBPF/XDP und NetFlow liefert detaillierte Netzwerk-Telemetrie über alle Schichten – von physischen Servern bis hin zu Kubernetes-Clustern. Es überwindet die Grenzen herkömmlicher sFlow/NetFlow-Lösungen wie hohe Hardware-Kosten, Stichprobenverfahren und fehlende benutzerdefinierte Felder. Der Datenverkehr wird über eine einheitliche Router-on-a-stick-Schnittstelle verarbeitet, sodass XDP eingehende Pakete erfassen kann, ohne den Kernel zu modifizieren.

eBPF führt Programme sicher im Betriebssystemkern aus und mit minimaler Latenz, was es ideal für Echtzeit-Monitoring macht. Statistiken werden pro 5-Tupel (IP-Adressen, Ports, Protokoll), Bytes und Pakete erfasst und im NetFlow-Format an Sammler weitergeleitet.

Auswahl der BPF-Maps für maximale Leistung

BPF-Maps speichern Statistiken als Schlüssel-Wert-Tabellen: Der Schlüssel ist das 5-Tupel, der Wert sind Zähler. Tests ergaben Probleme mit BPF_MAP_TYPE_HASH:

• Lock-Konflikte bei mehrkerniger Zugriffslast.
• Race Conditions, die zu ungenauen Zählern führen.

Atomare Operationen (__sync_fetch_and_add) beseitigen Fehler, reduzieren aber die Performance aufgrund von Synchronisationskosten.

Der Wechsel zu BPF_MAP_TYPE_PERCPU_HASH erstellt pro CPU-Core eine separate Map, eliminiert damit Locks. Die Aggregation erfolgt im Benutzerbereich. Benchmark-Tests auf 100 Kernen unter unterschiedlichen Lasten bestätigten, dass PERCPU-Maps die beste Leistung erzielen.

Wenn voll (600K 5-Tupel in einer 60K-Einträge-Map), verdrängt BPF_MAP_TYPE_LRU_PERCPU_HASH alte Einträge – allerdings mit Kosten. Standard-PERCPU_HASH bleibt für schnelle, einmalige Lesevorgänge vorzuziehen.

// Bestimmt, in welche Map geschrieben wird
#define SHARD_COUNT 25 // Anzahl der Shards
map_hash_idx = ctx->rx_queue_index % SHARD_COUNT + shard_offset;

Map-Sharding und mehrthreadige Exportierung

Eine einzelne Map mit 10 Mio. Einträgen war durch einen einzigen Exporter geblockt. Durch Aufteilung in 25 Maps (basierend auf rx_queue_index via RSS) wurde paralleles Lesen ermöglicht und die Verarbeitung um das Dreifache beschleunigt.

Vorteile des Sharding:

• Skalierbarkeit: Hinzufügen von Maps ohne Neustart.
• Parallelität: Sensoren lesen mehrere Maps gleichzeitig.
• Cache-Effizienz: Kleine Maps passen in L1/L2-Cache.

Der Go-basierte Sensor (mit Cilium-Bibliotheken) nutzt BPF_MAP_LOOKUP_AND_DELETE_BATCH, um Maps jede Minute zu lesen und zu leeren – minimiert Datenverlust bei Überlauf.

Sampling und dynamische Lastanpassung

Um die Weiterleitungseffizienz mit Telemetrie-Anforderungen zu balancieren, wird Sampling implementiert. Eine sekundäre stats_map (BPF_MAP_TYPE_HASH, max_entries=128) zählt Pakete pro Shard:

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 128);  // Max. Anzahl der Shards
    __type(key, __u32);        // Shard-ID
    __type(value, __u64);      // Paket-/Byte-Zähler
    __uint(pinning, LIBBPF_PIN_BY_NAME);
} stats_map SEC(".maps");

eBPF-Timer berechnen periodisch die Durchsatzrate (Pakete/Sekunde) und aktivieren Sampling, wenn Schwellwerte pro Shard überschritten werden. Timer führen Hintergrundaufgaben außerhalb des Paketkontexts aus – aggregieren Daten und setzen Zähler zurück.

So bleibt die Stabilität auch bei plötzlichen Datenstürmen (wie DDoS) erhalten, während Session-Telemetrie gewahrt bleibt.

Anpassung an Virtualisierung und Kubernetes

Die Architektur für Bare Metal skaliert nahtlos auf virtuelle Umgebungen und Kubernetes. In K8s-Clustern läuft eBPF/XDP als DaemonSet und erfasst Pod-Traffic über CNI. Sharding passt sich der Node-Affinität an; PERCPU_HASH entspricht den vCPUs.

NetFlow-Export aggregiert Metadaten (Namespace, Pod-IP), was die Beobachtbarkeit von Microservices verbessert.

Wichtige Erkenntnisse:

• PERCPU_HASH beseitigt Lock-Konflikte und steigert die Durchsatzrate um das 2–3-Fache gegenüber HASH.
• Sharding beschleunigt den Export um das Dreifache durch Parallelität.
• eBPF-Timer + Sampling halten die Last im Gleichgewicht, ohne die Weiterleitung zu beeinträchtigen.
• LRU-Variante eignet sich für dynamische Szenarien mit Überlauf.
• Go-Sensor mit Cilium-Bibliotheken überzeugt bei hochdurchsatzorientierter Analyse.

— Editorial Team