Docker Overlay-Netzwerk Leistung in Kubernetes – Analyse und Optimierung

Kubernetes nutzt seit Jahren das Docker‑Overlay‑Netzwerk als Standardmechanismus zur Verbindung von Pods im Cluster. Obwohl diese Lösung einfach zu konfigurieren ist, zeigt sie in Produktionsumgebungen eine Reihe von Leistungs‑ und Architektur‑Einschränkungen. In diesem Artikel werfen wir einen Blick auf die internen Mechanismen des Docker‑Overlay, führen kurze Latenz‑ und Durchsatz‑Tests durch und stellen die häufigsten Stolperfallen vor, denen DevOps‑Ingenieure begegnen. Am Ende findest du eine praktische Checkliste sowie Leitlinien, wann es sinnvoll ist, ein Overlay zu wählen und wann man zu einem anderen Netzwerkmodell wechseln sollte.

Wie das Docker‑Overlay‑Netzwerk in Kubernetes funktioniert

Ein Overlay ist eine virtuelle Schicht, die auf einem bestehenden physischen Netzwerk (z. B. Ethernet) aufgebaut wird. Jeder Pod erhält eine eigene IP‑Adresse aus dem Bereich 10.244.0.0/16 (standardmäßig), und Docker verwendet libnetwork sowie iptables zur Kapselung des Datenverkehrs in VXLAN‑Tunneln. Das Paket, das den Pod verlässt, wird zuerst an das virtuelle Interface cbr0 übergeben, dann im VXLAN‑Header gekapselt und über das physische Host‑Interface gesendet.

Schlüsselelemente:

• VXLAN (Virtual Extensible LAN) – bietet einen 24‑Bit‑Segment‑Identifier (VNI), der die Isolation mehrerer Cluster in einem Netzwerk ermöglicht.
• iptables NAT – übersetzt Pod‑Adressen in Host‑Adressen, wodurch die Kommunikation außerhalb des Clusters möglich wird.
• IPVS / kube-proxy – übernimmt das Load‑Balancing von Services, fügt im iptables-Modus jedoch eine zusätzliche NAT‑Kette hinzu, was die Regelanzahl erhöht.

Warum ist das wichtig? Jeder zusätzliche Sprung (VXLAN → iptables → IPVS) verursacht Zeit‑Overhead und erhöht die CPU‑Auslastung, was in großen Clustern zum Engpass werden kann.

Vergleich Docker‑Bridge und Overlay – was wählen?

Docker‑Bridge ist eine einfache L2‑Brücke, die auf Ebene eines einzelnen Hosts arbeitet. Pakete werden nicht gekapselt, wodurch der VXLAN‑Overhead entfällt, jedoch ist eine manuelle Routing‑Konfiguration zwischen den Hosts erforderlich. Das Overlay hingegen funktioniert „out‑of‑the‑box“ und verbindet automatisch alle Knoten, jedoch auf Kosten zusätzlicher Verarbeitung.

In der Praxis:

• Bridge bietet niedrigere Latenz (< 0,2 ms) und höheren Durchsatz (bis zu 10 Gbps) in kleinen, ein‑Knoten‑Umgebungen.
• Overlay fügt zusätzliche 0,5‑1 ms Latenz hinzu und begrenzt den Durchsatz auf 2‑3 Gbps bei voller CPU‑Auslastung.

Die Wahl hängt von den Anforderungen ab: Wenn du eine einfache, hochperformante Verbindung in einer geschlossenen Testumgebung benötigst – Bridge. In einem Multi‑Node‑Cluster, wo die automatische Topologie entscheidend ist – Overlay.

Leistungstests – was messen?

Zur Messung der Overlay‑Leistung wird häufig iperf3 und ping zwischen zwei Pods auf verschiedenen Knoten eingesetzt. Beispielhafte Befehle:

# starte iperf‑Server auf Node A
kubectl run iperf-server --image=networkstatic/iperf3 --restart=Never -- -s
# starte iperf‑Client auf Node B
kubectl run iperf-client --image=networkstatic/iperf3 --restart=Never -- -c iperf-server -t 30
# Latenz‑Messung
kubectl exec -it iperf-client -- ping -c 10 iperf-server

In einem typischen 5‑Node‑Cluster (AWS m5.large) wurde ein durchschnittlicher Durchsatz von ~2,4 Gbps und eine Latenz von 0,8 ms mit Overlay erreicht. Im Vergleich dazu sank die Latenz bei Bridge auf 0,3 ms, während der Durchsatz auf 7,8 Gbps anstieg.

Wann Overlay einsetzen und wann nicht?

Wann einsetzen:

• Multi‑Node‑Umgebungen mit dynamischer Pod‑Skalierung.
• Erforderliche Netzwerkisolierung zwischen verschiedenen Teams oder Umgebungen (z. B. dev vs. prod).
• Bedarf an einem einfachen Netzwerkmodell ohne manuelle Routing‑Konfiguration.

Wann nicht einsetzen:

• Maximale Bandbreite und minimale Latenz sind entscheidend (z. B. Datenbanken, Hochleistungs‑HPC).
• Du hast volle Kontrolle über die Infrastruktur und kannst L2/L3‑Routing manuell verwalten.
• In Clustern mit sehr hoher Pod‑Anzahl (> 10 000) werden iptables‑Regeln unüberschaubar.

Typische Produktionsfallen und deren Beseitigung

1. Überfüllte iptables‑Tabelle – bei einer großen Anzahl von Services erzeugt kube‑proxy tausende Regeln, was die Paketverarbeitung verlangsamt. Lösung: kube‑proxy in den IPVS-Modus schalten, der Hash‑Tabellen nutzt und deutlich schneller ist.

2. VXLAN‑Fragmentierung – falsches MTU (standardmäßig 1500) führt zu Fragmentierung und erhöht die Latenz. Empfehlung: MTU auf 1450 für das Interface cbr0 setzen und das MTU im Subnetz‑Layer anpassen.

3. Fehlendes CNI‑Monitoring – Latenz‑Probleme resultieren häufig aus falscher CNI‑Konfiguration (z. B. Flannel vs. Calico). Verwende Prometheus + cAdvisor + kube‑network‑policy zur Erfassung der Metriken container_network_receive_bytes_total und container_network_transmit_errors_total.

„Overlay ist Komfort, keine Magie – ohne bewusste Optimierung wird es zum Engpass jeder Anwendung, die niedrige Latenz erfordert.”

Praktisches Beispiel – Implementierungs‑Checkliste

Nachfolgend die fertige Schritt‑Liste, die in jedem Playbook zur Vorbereitung eines Kubernetes‑Clusters für die Produktion mit Docker‑Overlay‑Network enthalten sein sollte:

• Überprüfen Sie die Docker‑ und kube‑proxy‑Version (mindestens 1.20/1.21) – neuere Versionen bringen Verbesserungen bei der VXLAN‑Unterstützung.
• Setzen Sie MTU 1450 auf dem Interface cbr0 und verifizieren Sie das Fehlen von Fragmentierung (ping -M do -s 1400).
• Schalten Sie kube‑proxy auf IPVS um (kubectl edit cm kube-proxy -n kube-system).
• Aktivieren Sie das CNI‑Monitoring (Prometheus + node‑exporter) und konfigurieren Sie Alarme für network_latency_seconds > 1.
• Erwägen Sie alternative CNI‑Lösungen (Calico, Cilium) bei hohen Sicherheits‑ oder Leistungsanforderungen.

Nach Durchführung der oben genannten Schritte werden die meisten typischen Latenz‑ und Durchsatzprobleme eliminiert, und der Cluster ist bereit, Produktions‑Workloads zu bedienen.

Fazit und Einladung zur Zusammenarbeit

Docker‑Overlay‑Network in Kubernetes ist ein leistungsstarkes Werkzeug, das den Netzwerkaufbau in großen Clustern vereinfacht, jedoch eine bewusste Optimierung hinsichtlich Performance erfordert. Das Verständnis von VXLAN, iptables und IPVS hilft, die häufigsten Stolperfallen zu vermeiden, und die Anwendung der praktischen Checkliste sorgt für Stabilität in Produktionsumgebungen. Wenn Sie Unterstützung bei der Netzwerk‑Audit, Migration zu einem leistungsfähigeren CNI oder der Implementierung fortschrittlichen Monitorings benötigen, steht das Team von Coderia.it bereit, Ihr Projekt zu unterstützen – kontaktieren Sie uns noch heute.