K8s-Network-Benchmarking: iperf vs. Real Workload (was ist valide?)

K8s-Network-Benchmarking ist in der Praxis deutlich schwieriger, als es auf den ersten Blick wirkt: Ein schneller iperf-Test zwischen zwei Pods liefert beeindruckende Durchsatzwerte – und trotzdem klagen Anwendungen über Timeouts, hohe P99-Latenzen oder sporadische Verbindungsabbrüche. Der Grund ist einfach: iperf misst einen sehr spezifischen Ausschnitt (meist TCP-Stream-Durchsatz) unter kontrollierten Bedingungen, während reale Workloads aus vielen kleinen Requests, wechselnden Payloads, unterschiedlichen Concurrency-Mustern, TLS, Retries, Sidecars, Service-Mesh-Gateways und Node-Überlastung bestehen. Wer valide Aussagen treffen will, muss zuerst klären, welche Frage das Benchmarking beantworten soll: „Wie schnell kann das Netzwerk theoretisch?“ ist eine andere Frage als „Wie zuverlässig ist mein Service unter Last?“ oder „Welche CNI-/kube-proxy-Konfiguration liefert die niedrigste Tail Latency?“ Dieser Artikel zeigt, wann iperf sinnvoll ist, wann es in die Irre führt und wie Sie K8s-Network-Benchmarking so aufbauen, dass Ergebnisse belastbar sind – inklusive konkreter Testdesigns, Metriken und typischer Fallstricke.

Was bedeutet „valide“ beim K8s-Network-Benchmarking?

„Valide“ heißt im Benchmarking-Kontext: Die Messung repräsentiert das Systemverhalten für einen definierten Zweck und ist reproduzierbar. In Kubernetes können zwei Messungen mit identischem Tool und identischer Commandline unterschiedliche Ergebnisse liefern, wenn sich nur ein Detail ändert – beispielsweise Pod-Platzierung, Node-CPU-Sättigung, conntrack-Status, MTU, Service-Routing oder TLS-Offload. Valide ist ein Benchmark daher nur, wenn Sie die Testbedingungen dokumentieren, Störfaktoren minimieren und die Messwerte mit den realen Betriebszielen verknüpfen.

• Zweckklarheit: Suchen Sie maximale Bandbreite, minimale Latenz, Stabilität unter Concurrency oder Fehlerverhalten?
• Reproduzierbarkeit: Gleiche Ergebnisse über mehrere Läufe, Nodes und Zeitpunkte (mit definierter Varianz).
• Repräsentativität: Ähnliches Traffic-Profil wie der reale Workload (Payload, Protokoll, Verbindungsmodell).
• Interpretierbarkeit: Sie können erklären, warum sich Ergebnisse ändern (z. B. CPU-Limit, NAT, iptables-Regeln).

iperf in Kubernetes: Stärken, typische Missverständnisse und geeignete Einsatzfälle

iperf (bzw. iperf3) ist ein etabliertes Tool, um Netzwerk-Performance zu messen. In Kubernetes wird es häufig in Pods gestartet, um den Durchsatz zwischen zwei Endpunkten zu prüfen. Das ist nützlich, weil Sie damit schnell sehen, ob ein offensichtliches Bandbreitenproblem vorliegt oder ob ein Pfad grundsätzlich funktioniert. Aber iperf ist kein Allzweck-Proxy für „Anwendungsperformance“.

Was iperf gut misst

• TCP-Stream-Durchsatz: Maximale Datenrate für eine (oder mehrere) TCP-Verbindungen.
• UDP-Durchsatz und Loss: Wenn Sie UDP testen, bekommen Sie Hinweise auf Paketverlust bei hoher Sendeleistung.
• Vergleichstests: Vorher/Nachher beim Wechsel von CNI, MTU, Node-Typ, Kernel-Settings.
• Pfad- und Offload-Effekte: Unterschiede zwischen Pod-to-Pod, Pod-to-Service, NodePort, Ingress.

Wo iperf regelmäßig in die Irre führt

• Latenz und Tail Latency: Ein hoher Durchsatz sagt wenig über P95/P99-Latenz aus.
• Request/Response-Profile: Reale Services nutzen oft viele kleine Requests statt großer Streams.
• TLS- und CPU-Kosten: iperf misst meist „plain“ Traffic; TLS-Handshakes und Encryption fehlen.
• Connection Churn: Viele kurze Verbindungen (z. B. HTTP/1.1 ohne Keep-Alive) belasten conntrack und NAT anders.
• Service Chains: Sidecars, Mesh-Gateways, WAFs oder Proxies in der Realität fehlen im iperf-Pfad.

Für Referenz und Optionen (Parallel Streams, UDP-Mode, JSON-Output) lohnt sich der Blick in die iperf3-Dokumentation: iperf3 (ESnet) – Repository und Usage.

Real Workload Benchmarking: Warum es teurer ist – und warum es sich lohnt

Ein „Real Workload“-Benchmark versucht, das Verhalten Ihrer Anwendung oder Ihrer zentralen Kommunikationspfade realistisch zu imitieren. Das heißt nicht, dass Sie exakt die Produktion kopieren müssen. Es heißt aber, dass Sie die Eigenschaften übernehmen, die Performance und Stabilität tatsächlich bestimmen: Protokoll (HTTP/gRPC), Payload-Verteilung, Concurrency, Verbindungspooling, Timeouts, Retries, TLS, Header-Größen, Kompression, Streaming vs. Unary Calls, sowie Fehlerpfade (z. B. Backends zeitweise langsam).

• Repräsentative Metriken: P50/P95/P99, Error Rate, Retry Rate, Saturation, Queueing.
• Realistische Pfade: Über Service, über Ingress, über Mesh, über Gateway – so wie im Betrieb.
• Fehlertoleranz sichtbar machen: Wie verhält sich die Anwendung bei Paketverlust, Jitter, DNS-Flaps, Partial Outages?

Werkzeuge für HTTP- oder gRPC-Lasttests (z. B. vegeta, k6, wrk2, fortio) sind oft besser geeignet als iperf, wenn das Ziel „Service-Performance“ heißt. Für k6 als verbreitetes Load-Testing-Tool ist die offizielle Dokumentation eine solide Ausgangsbasis: k6 – Dokumentation. Für Fortio als Tool, das speziell in Cloud-Native-Umgebungen häufig genutzt wird: Fortio – Repository und Beispiele.

Die zentrale Frage: Was wollen Sie messen – Bandbreite, Latenz oder Zuverlässigkeit?

Viele Benchmark-Probleme entstehen, weil Ziele vermischt werden. Bandbreite, Latenz und Zuverlässigkeit hängen zusammen, aber sie sind nicht austauschbar. Ein Cluster kann hohen Durchsatz liefern und trotzdem unter Last instabil werden, wenn CPU, conntrack oder Queues überlaufen. Umgekehrt kann ein System niedrige Median-Latenz haben, aber schlechte Tail Latency, wenn einzelne Pfade sporadisch blockieren.

• Bandbreite (Throughput): Datenrate pro Zeit (z. B. Gbit/s, MiB/s).
• Latenz (Latency): Zeit pro Request/Response (wichtig: P95/P99).
• Zuverlässigkeit: Erfolgsquote, Timeouts, Resets, Retries, Packet Loss, Reordering.

Ein praktischer Zusammenhang: Bandbreite, RTT und „in-flight“ Daten

Wenn Sie verstehen wollen, warum ein Pfad trotz hoher Bandbreite „träge“ wirkt, hilft das Konzept Bandwidth-Delay Product (BDP). Es beschreibt, wie viele Bits auf einem Pfad gleichzeitig „unterwegs“ sein können:

$\mathrm{BDP}=\mathrm{Bandwidth}\times \mathrm{RTT}$

Ist die TCP-Fenstergröße kleiner als das BDP, wird ein Pfad nicht voll ausgenutzt. In Kubernetes kann das z. B. bei Cross-Zone-/Cross-Region-Traffic oder bei Service-Mesh-Pfaden relevant werden, weil zusätzliche Hops die RTT erhöhen.

Testdesign in Kubernetes: Welche Pfade müssen Sie getrennt betrachten?

„Netzwerk in Kubernetes“ ist nicht ein Pfad. Je nach Traffic-Route greifen unterschiedliche Komponenten: CNI-Datapath, kube-proxy (iptables/IPVS), eBPF-Implementierungen, Overlay/Underlay, NAT, conntrack, Ingress Controller, Service Mesh Sidecars. Ein valider Benchmark trennt diese Pfade und vergleicht sie systematisch.

• Pod-to-Pod (same node): Minimiert Underlay-Effekte, zeigt CNI-/Kernel-Overhead.
• Pod-to-Pod (cross node): Testet Underlay, Routing, ggf. Overlay (VXLAN/IPIP), MTU.
• Pod-to-Service (ClusterIP): Bezieht kube-proxy oder eBPF-Service-LB ein.
• Pod-to-NodePort/LoadBalancer: Relevant für „North-South“ und externe Clients.
• Ingress-to-Service: Enthält Proxying, TLS-Termination, Header-Verarbeitung, Timeouts.
• Mesh Sidecar-to-Sidecar: Zusätzliche Hops, mTLS, Filter Chains, Telemetrie-Kosten.

Wenn Sie kube-proxy-Varianten und deren Auswirkungen verstehen wollen, ist der offizielle Kubernetes-Hintergrund hilfreich: kube-proxy – Referenz.

iperf vs. Real Workload: Wann ist welches Tool valide?

Eine pragmatische Regel: iperf ist valide, wenn Sie isoliert den Transportpfad testen wollen. Real-Workload-Tests sind valide, wenn Sie Serviceverhalten, SLOs oder Nutzererfahrung bewerten. In der Praxis brauchen Sie beides – aber in der richtigen Reihenfolge und mit klarer Interpretation.

• iperf ist valide für: Kapazitätschecks, Pfadvergleiche, Regressionstests nach CNI-/Kernel-Changes, schnelle Hypothesen („Ist der Pfad grundsätzlich schnell genug?“).
• iperf ist nicht valide für: API-Latenz, gRPC-Fehlerbilder, TLS-Probleme, Retry-Verhalten, Queueing in Proxies.
• Real Workload ist valide für: P95/P99, Error Budgets, Timeout-Strategien, Mesh-/Ingress-Overhead, SLO-Validierung.
• Real Workload ist nicht valide für: reine Link-Kapazität ohne Applikations-Stack (zu viele Variablen).

Die häufigsten Fehler beim K8s-Network-Benchmarking

Viele Benchmarks scheitern nicht am Tool, sondern am Setup. Besonders in Kubernetes werden Ergebnisse durch Scheduling und Ressourcenlimits verfälscht. Die folgenden Fehler tauchen in der Praxis am häufigsten auf.

• CPU-Limits ignoriert: Der Benchmark ist CPU-bound (TLS, Sidecar, iptables), nicht network-bound.
• Unkontrollierte Pod-Platzierung: „Same node“ vs. „cross node“ wird zufällig gemischt.
• Nur Durchschnittswerte: Mean/Avg verschleiert Tail Latency; P95/P99 fehlen.
• Warm-up fehlt: Caches, JIT, conntrack, TLS Session Resumption sind nicht stabil.
• Zu kurze Testdauer: Kurztests sehen gut aus, Langläufe zeigen Leaks, Drops, Flaps.
• Fehlende Hintergrundlast: Produktion hat Nachbarpods, Interrupt-Last, IO – Benchmarks laufen „im Labor“.
• MTU und Fragmentation übersehen: Große Payloads scheitern, kleine funktionieren.
• NAT/conntrack nicht beobachtet: Hohe Connection Rates führen zu Drops, die iperf kaum sichtbar macht.

Ein belastbares Benchmark-Setup: Schritt-für-Schritt-Vorgehen

Ein guter Ansatz ist eine zweistufige Teststrategie: zuerst ein Transport-Baseline-Test (z. B. iperf), dann ein Workload-naher Test (HTTP/gRPC), jeweils getrennt nach Pfaden. Wichtig ist, die Umgebung so zu kontrollieren, dass Sie Änderungen eindeutig zuordnen können.

Schritt: Testumgebung kontrollieren

• Dedizierte Nodes (wenn möglich): Taints/Tolerations oder Node Pools, um Nachbarlast zu reduzieren.
• Feste Pod-Affinity/Anti-Affinity: Erzwingen, ob Pods auf demselben oder auf verschiedenen Nodes laufen.
• Ressourcen sauber setzen: CPU- und Memory-Requests/Limits definieren, um Throttling zu erkennen.
• Netzwerkpfad dokumentieren: CNI, kube-proxy Mode, Overlay/Underlay, MTU, Mesh ja/nein.

Schritt: Baseline mit iperf (Transport)

• TCP und optional UDP: TCP für Durchsatz, UDP für Loss unter Last (vorsichtig interpretieren).
• Mehrere parallele Streams: Ein Stream zeigt nicht immer die tatsächliche Link-Kapazität.
• Testdauer ausreichend: Nicht nur 5 Sekunden, sondern z. B. 60–180 Sekunden plus Wiederholungen.
• JSON-Output speichern: Auswertung automatisierbar machen, Varianz beobachten.

Schritt: Workload-naher Test (Service-Verhalten)

• HTTP/gRPC passend zur App: Keep-Alive, Header-Größen, Payload-Verteilung realistisch.
• Concurrency und RPS staffeln: Ramp-up, Plateau, Ramp-down, um Sättigung zu erkennen.
• Tail Latency messen: P95/P99, nicht nur Median.
• Fehler messen: Timeouts, Resets, Retries, TLS Errors, DNS Errors.

Welche Metriken müssen Sie zwingend erfassen?

Ohne Telemetrie ist Benchmarking in Kubernetes reine Zahlenmagie. Sie brauchen Metriken aus drei Ebenen: Client/Load-Generator, Netzwerkpfad und Systemressourcen. Nur dann können Sie erklären, ob ein „Netzwerkproblem“ in Wahrheit CPU-Throttling, conntrack-Sättigung oder Proxy-Queueing war.

• Client-Sicht: Latenz-Percents (P50/P95/P99), Throughput (RPS), Error Codes, Timeouts, Retries.
• Node-Sicht: CPU (gesamt + throttling), IRQ/SoftIRQ, Load, NIC Drops, TCP Retransmits.
• Netzwerkpfad: conntrack usage, iptables/ebpf Drops, CNI-spezifische Drops, MTU-Frag-Indikatoren.
• Proxy/Mesh: Queueing, upstream connect time, TLS handshake time, circuit breaker events.

Für tieferes Verständnis und Tools im Linux-Umfeld (perf, eBPF, system-level Analysis) ist Brendan Greggs Performance-Übersicht ein bewährter Einstieg: Linux Performance Tools (Brendan Gregg).

Validierungslogik: Wie Sie iperf-Ergebnisse gegen Real-Workload-Ergebnisse abgleichen

Eine gute Praxis ist eine einfache Plausibilitätskette: Wenn iperf „sehr schnell“ ist, aber Real-Workload „langsam“, dann liegt das Problem oft nicht an der reinen Link-Kapazität, sondern an Overhead im Stack oder an Sättigungseffekten. Umgekehrt: Wenn iperf bereits schlecht ist, lohnt sich Real-Workload-Benchmarking erst, nachdem Sie den Transportpfad stabilisiert haben.

• iperf gut, Workload schlecht: Prüfen Sie CPU/Throttling, TLS, Sidecars, Proxy-Timeouts, conntrack, Service-Routing.
• iperf schlecht, Workload schlecht: Prüfen Sie CNI/Overlay, MTU, Underlay, NIC/Node-Health, Netzwerkpolicies.
• iperf gut, Workload instabil (Errors): Fokus auf DNS, mTLS, Connection Churn, Rate Limits, Retries.
• iperf schwankt stark: Hintergrundlast, noisy neighbors, IRQ-Sättigung, CPU frequency scaling, node-level contention.

Spezielle Kubernetes-Fallen: kube-proxy, conntrack und Service-Load-Balancing

Viele „Netzwerkbenchmarks“ messen in Wirklichkeit kube-proxy- oder conntrack-Verhalten. Insbesondere bei hoher Connection Rate (viele neue TCP-Verbindungen pro Sekunde) wird conntrack zum Engpass. Das gilt noch stärker, wenn NAT im Spiel ist (NodePort, LoadBalancer, Egress NAT, Masquerade). Ein Real-Workload-Test mit kurzlebigen Verbindungen kann deshalb dramatisch schlechter aussehen als ein iperf-Test mit wenigen langlebigen Streams.

• Symptom: Steigende Timeouts/Resets bei hoher Concurrency, trotz guter Bandbreite.
• Hinweis: TCP Retransmits steigen, conntrack table nähert sich Limit, Drops häufen sich.
• Abhilfe: Verbindungspooling/Keep-Alive, HTTP/2/gRPC, conntrack tuning, eBPF-basierte LB-Optionen prüfen.

Benchmarking-Formate, die in der Praxis funktionieren

In Teams mit regelmäßigem Plattformbetrieb sind wiederholbare Benchmark-Formate entscheidend. Ziel ist nicht, „einmal“ die höchste Zahl zu bekommen, sondern Trends und Regressionen zu erkennen, etwa nach CNI-Updates, Kernel-Änderungen oder Node-Type-Wechseln.

• Regressionssuite: Ein kurzer iperf-Baseline-Test plus ein repräsentativer HTTP/gRPC-Test pro Pfad (same node/cross node/service/ingress).
• Canary-Benchmarking: Neue CNI-/Kernel-Version zuerst auf einem Node Pool testen, dann ausrollen.
• Soak-Tests: Längere Läufe (z. B. 1–6 Stunden) zur Erkennung von Leaks, Flaps, langsamem Degradieren.
• Fehler-injizierte Tests: Paketverlust/Jitter simulieren, DNS-Störungen, Pod-Reschedules, um Robustheit zu prüfen.

Outbound-Links für vertiefende Praxisquellen

• iperf3 – Offizielle Quelle (ESnet)
• Kubernetes Services & Networking – Grundlagen und Pfade
• kube-proxy – Referenz und Betriebsaspekte
• k6 – Load Testing für realistische HTTP-Workloads
• Fortio – Latency/Load Tool für Cloud-Native Pfade
• Linux Performance Tools – Systemanalyse für Bottleneck-Findung

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.