kube-proxy, iptables und das Problem „Conntrack Full“

kube-proxy, iptables und das Problem „Conntrack Full“ gehören zu den häufigsten Ursachen für schwer erklärbare Netzwerkstörungen in Kubernetes-Clustern: Verbindungen schlagen plötzlich fehl, Services sind sporadisch nicht erreichbar, Requests hängen in Timeouts, und die Fehler treten scheinbar zufällig auf – oft nur unter Lastspitzen oder bei bestimmten Traffic-Mustern. Hinter dem Symptom „Conntrack Full“ steckt in vielen Fällen kein einzelner Bug, sondern eine Kombination aus Service-Routing (kube-proxy im iptables-Modus), NAT-Regeln, hoher Verbindungsrate und einem zu klein dimensionierten Connection-Tracking-Table im Linux-Kernel. Sobald die Conntrack-Tabelle ausgelastet ist, kann der Node neue Verbindungen nicht mehr sauber nachverfolgen. Das betrifft nicht nur einzelne Pods, sondern häufig den gesamten Node – und damit alle Services, die über ihn geroutet werden. Wer kube-proxy, iptables und Conntrack als zusammenhängendes System versteht, kann die Ursache zielgerichtet eingrenzen: Welche Flows erzeugen die Einträge? Warum wachsen sie? Welche Timeouts verhindern die Bereinigung? Und welche Stellschrauben helfen wirklich, ohne die Sicherheit oder Stabilität des Clusters zu gefährden?

Was kube-proxy in Kubernetes tut und warum das relevant ist

kube-proxy ist die Standardkomponente, die Kubernetes-Services auf den Nodes umsetzt. Ein Service (ClusterIP, NodePort, LoadBalancer) ist ein virtueller Endpunkt, der auf eine dynamische Menge an Pod-Endpunkten (Endpoints/EndpointSlices) abbildet. kube-proxy sorgt dafür, dass Traffic an die Service-IP und den Service-Port ankommt und anschließend an ein konkretes Backend (Pod-IP:Port) weitergeleitet wird. Dazu programmiert kube-proxy Regeln in den Netzwerk-Stack des Nodes, typischerweise über iptables oder IPVS. In vielen Clustern ist der iptables-Modus der Default.

• Service-VIP: stabile Ziel-IP (ClusterIP), die zu wechselnden Pods routet
• Lastverteilung: Auswahl eines Backends nach Regeln (z. B. random/statistisch)
• Implementierung: iptables (häufig) oder IPVS (alternativ), abhängig von Cluster-Setup

Grundlagen zu Services und kube-proxy: Kubernetes Services und kube-proxy Referenz.

iptables im kube-proxy-Kontext: Warum NAT und Chains eine Rolle spielen

Im iptables-Modus baut kube-proxy Regelketten auf, die eingehenden Traffic zur Service-IP abfangen und per DNAT auf ein Backend umschreiben. Das ist effektiv, aber es bringt zwei Eigenschaften mit, die direkt mit „Conntrack Full“ zusammenhängen: Erstens nutzt NAT den Connection Tracker, um Verbindungen zustandsbehaftet zu übersetzen. Zweitens erhöht jede zusätzliche NAT- oder Filterlogik den Druck auf den Kernel, Zustände sauber zu pflegen.

• DNAT: Service-IP wird auf Pod-IP umgeschrieben
• SNAT: Rückwege und bestimmte Pfade benötigen Source-NAT (z. B. bei NodePort/ExternalTrafficPolicy)
• Zustand: NAT ist ohne Conntrack kaum sinnvoll, weil Rückpakete korrekt zugeordnet werden müssen

Wenn Sie verstehen wollen, wie kube-proxy iptables-Regeln aufbaut, ist die Kubernetes-Dokumentation zu Services und Proxying der beste Einstieg. Die iptables-Grundlagen (Netfilter) sind im Linux-Ökosystem verankert; als Orientierung dient der Überblick zu Netfilter/iptables Dokumentation.

Was Conntrack ist und warum „Conntrack Full“ so destruktiv ist

Conntrack (Connection Tracking) ist eine Kernel-Funktion, die Netzwerkflüsse als Zustände verwaltet. Für TCP wird z. B. verfolgt, ob ein Flow im SYN-Send, Established, FIN-Wait usw. ist. Für UDP werden „Pseudo-States“ mit Timeouts geführt, weil UDP zustandslos ist. Sobald Conntrack aktiv ist (und in Kubernetes ist es das praktisch immer), wird für viele Flows ein Eintrag in der Conntrack-Tabelle angelegt. Diese Tabelle hat eine maximale Größe (Limit). Wenn sie voll ist, können keine neuen Einträge mehr angelegt werden. Die Folgen sind drastisch:

• Neue Verbindungen können nicht zuverlässig aufgebaut werden (Timeouts, Drops)
• NAT-Übersetzungen können nicht korrekt erfolgen
• Einzelne Nodes „wirken tot“, obwohl CPU/Memory noch gut aussehen
• Fehlerbilder sind sporadisch, weil bestehende Verbindungen oft weiterlaufen

Für Details zum Conntrack-Subsystem und dessen Parameter ist die Netfilter-Dokumentation ein sinnvoller Einstieg, insbesondere die Hinweise zu nf_conntrack und Timeouts unter Netfilter Dokumentation.

Warum kube-proxy (iptables) Conntrack besonders stark belasten kann

Conntrack-Probleme entstehen nicht „nur durch kube-proxy“, aber kube-proxy im iptables-Modus ist ein häufiger Verstärker, weil Services regelmäßig NAT involvieren. Besonders bei Traffic-Mustern mit vielen kurzlebigen Verbindungen (Short-Lived TCP) oder vielen UDP-Flows (DNS, Telemetrie, Log-Pipelines) wächst die Conntrack-Tabelle schnell. Zusätzlich gibt es Cluster-spezifische Pfade, die mehr Conntrack-Einträge erzeugen, als Teams erwarten.

Typische Verstärker im Kubernetes-Umfeld

• Hohe Verbindungsrate: viele neue TCP-Verbindungen pro Sekunde (z. B. fehlendes Connection Reuse)
• UDP-lastige Workloads: DNS-Spitzen, StatsD/Telemetry, Service Discovery-Noise
• NodePort/LoadBalancer-Pfade: zusätzliche NAT-Schritte, je nach Konfiguration
• Hairpin Traffic: Pod erreicht Service, Backend liegt auf demselben Node; je nach Setup entstehen zusätzliche Zustände
• Retry-Stürme: wenn Backends langsam werden, steigen Retries, dadurch explodieren neue Flows

In vielen Incidents ist „Conntrack Full“ nicht die eigentliche Ursache, sondern die Folge einer Lastspirale: Ein Backend wird langsamer, Clients retrien aggressiver, die Verbindungsrate steigt, Conntrack füllt sich, und dadurch werden noch mehr Requests langsam oder fehlschlagen.

Die wichtigsten Symptome: Wie „Conntrack Full“ in der Praxis aussieht

Teams erwarten oft eine klare Fehlermeldung. In der Realität sehen Sie eher eine Mischung aus Zeitüberschreitungen, sporadischer Nichterreichbarkeit und schwer reproduzierbaren Ausfällen. Besonders typisch ist: „Ein Node ist komisch, ein anderer funktioniert.“ Das passt dazu, dass Conntrack pro Node geführt wird.

• Timeouts statt sofortiger Errors: Verbindungen hängen, statt aktiv abgelehnt zu werden
• Nur neue Verbindungen betroffen: bestehende Sessions funktionieren oft weiter
• DNS-Probleme: Cluster-DNS wirkt plötzlich unzuverlässig, weil UDP-Flows nicht sauber verfolgt werden
• Service-Erreichbarkeit schwankt: gleiche Anfrage klappt, dann nicht, abhängig vom Node-Pfad
• Knotenbezogen: Probleme konzentrieren sich auf einzelne Nodes oder Nodepools

Conntrack-Mechanik verstehen: Warum Timeouts entscheidend sind

Eine Conntrack-Tabelle füllt sich nicht nur durch neue Flows, sondern auch dadurch, wie lange Einträge bestehen bleiben. Selbst bei moderater Last kann Conntrack voll laufen, wenn Timeouts ungünstig sind oder Flows in „halboffenen“ Zuständen hängen. TCP-States können bei Netzwerkproblemen oder aggressiven Firewall-/NAT-Konfigurationen länger bestehen bleiben als erwartet. UDP-Einträge bleiben für eine definierte Zeit im Table, auch wenn die Kommunikation längst vorbei ist.

Warum UDP in Kubernetes oft unterschätzt wird

UDP gilt als „leichtgewichtig“, kann aber Conntrack stark belasten, wenn viele unterschiedliche 5-Tuples entstehen (Quelle-IP/Port, Ziel-IP/Port, Protokoll). DNS ist das bekannteste Beispiel: Bei hoher Request-Rate und vielen Clients entstehen schnell sehr viele kurze UDP-Flows. Wenn zusätzlich Retries passieren oder Timeouts hoch sind, wächst die Tabelle deutlich schneller als geplant.

Die Fehlerquelle eingrenzen: Ist es wirklich kube-proxy/iptables oder etwas anderes?

Conntrack Full kann auch ohne Services auftreten, etwa durch reinen Pod-Egress (viele ausgehende Verbindungen ins Internet), durch Node-local Agents, durch HostNetwork-Workloads oder durch Load-Tests. Deshalb ist die Diagnose immer: Welche Traffic-Klasse füllt die Tabelle? Dazu gehören zwei Perspektiven: observability im Netzwerk und observability in Kubernetes.

• Netzwerkperspektive: Welche Protokolle (TCP/UDP) dominieren? Viele neue Verbindungen? Viele unterschiedliche Ziele?
• Kubernetesperspektive: Welche Services sind Hotspots? Welche Pods erzeugen Traffic-Spitzen? Gibt es neue Deployments mit anderem Verbindungsverhalten?
• Nodeperspektive: Betrifft es nur einen Pool (z. B. Ingress-Nodes) oder zufällige Nodes?

Warum iptables-Regelmenge und Service-Scale indirekt Conntrack beeinflussen

In großen Clustern wächst die Anzahl der iptables-Regeln, weil jeder Service und jeder Endpoint abgebildet werden muss. Das ist primär ein Performance- und Latenzthema, kann aber indirekt Conntrack-Probleme verschärfen: Wenn die Paketverarbeitung länger dauert, können Retries, Timeouts und Verbindungsabbrüche wahrscheinlicher werden. Mehr Retries bedeuten mehr neue Verbindungen und damit mehr Conntrack-Einträge. Das ist besonders relevant bei vielen Services, vielen Endpoints und hohem Durchsatz.

Wann IPVS oder eBPF eine Alternative ist

IPVS kann bei großen Service-Tabellen effizienter sein als iptables, weil es Load-Balancing im Kernel strukturierter abbildet. eBPF-basierte Implementierungen (je nach CNI) können kube-proxy teilweise ersetzen oder entlasten. Wichtig ist: Auch IPVS und eBPF kommen nicht ohne Zustände aus, aber sie können die Skalierung und Observability verbessern und damit das Risiko reduzieren, in Conntrack-Spiralen zu geraten.

Die harten Stellschrauben: Conntrack-Limits und Dimensionierung

Wenn „Conntrack Full“ auftritt, ist eine unmittelbare Maßnahme oft die Anpassung der Conntrack-Kapazität. Das ist aber nicht automatisch die beste Dauerlösung, weil ein größeres Table mehr Memory verbraucht und das Grundproblem (Traffic-Pattern oder Retries) bestehen bleibt. Trotzdem ist Dimensionierung in Kubernetes wichtig, weil Default-Werte oft nicht zu großen oder traffic-intensiven Clustern passen.

Warum „mehr Conntrack“ nicht immer reicht

• Symptom statt Ursache: Retries, fehlerhafte Clients oder aggressive Healthchecks bleiben bestehen
• Memory-Kosten: Größere Tabellen brauchen mehr RAM, insbesondere auf kleineren Nodes
• Timeout-Fehlkonfiguration: Wenn Einträge zu lange hängen bleiben, füllt sich auch ein großes Table

Die weichen Stellschrauben: Traffic-Patterns so ändern, dass Conntrack stabil bleibt

Langfristig lösen Sie Conntrack-Probleme am zuverlässigsten, indem Sie die Entstehung neuer Zustände reduzieren und Retries kontrollieren. Das klingt nach „App-Thema“, ist aber in Kubernetes-Plattformbetrieb ein zentraler Stabilitätsfaktor. Viele Cluster-Incidents entstehen, weil Anwendungen Verbindungen nicht wiederverwenden oder weil Timeouts und Retry-Policies ungünstig kombiniert sind.

Praktische Maßnahmen, die Conntrack-Last senken

• Connection Reuse: HTTP Keep-Alive, HTTP/2, gRPC mit langlebigen Verbindungen statt „eine Verbindung pro Request“
• Client-Timeouts und Retries: Retries begrenzen, Backoff nutzen, Circuit Breaker einsetzen
• DNS optimieren: NodeLocal DNSCache prüfen, um DNS-Flows zu reduzieren (je nach Setup)
• Healthchecks prüfen: zu aggressive Checks können Flows massiv erhöhen, besonders bei vielen Pods
• Batching/Pooling: Datenbanken/Queues über Pools nutzen statt ständig neue Sessions aufzubauen

kube-proxy-spezifische Fallstricke: NodePort, ExternalTrafficPolicy und SNAT

Bestimmte Service-Konfigurationen beeinflussen, ob SNAT eingesetzt wird, wie Rückwege laufen und wie viele Conntrack-Einträge entstehen. NodePort und LoadBalancer-Pfade sind dabei besonders relevant, weil hier externer Traffic in den Cluster kommt und oft über zusätzliche NAT-Schritte geführt wird. Auch die Wahl von ExternalTrafficPolicy kann Auswirkungen auf Quell-IP-Sichtbarkeit und Routing haben und damit indirekt die Conntrack-Last verändern.

• ExternalTrafficPolicy=Cluster: kann zusätzliche Weiterleitung und SNAT-Pfade erzeugen
• ExternalTrafficPolicy=Local: reduziert manche Umwege, erfordert aber passende Pod-Platzierung auf Nodes
• Ingress-Controller-Nodes: konzentrieren Traffic, daher häufig zuerst von Conntrack Full betroffen

Debugging-Checkliste: Von Symptom zu blockierendem Engpass

Eine praxistaugliche Vorgehensweise ist, Conntrack-Probleme wie ein Kapazitäts- und Ursachenproblem zu behandeln: erst bestätigen, dann eingrenzen, dann stabilisieren, dann nachhaltig verbessern.

• 1) Node-Lokalität prüfen: Sind Ausfälle node-spezifisch oder clusterweit?
• 2) Fehlertyp klassifizieren: Timeouts (Drops/State) vs. Resets (App/Proxy) vs. DNS-Fehler
• 3) Traffic-Klassen bestimmen: TCP vs. UDP, intern vs. extern, Service-Pfad vs. Pod-IP-Pfad
• 4) Hotspots finden: Ingress/Gateway-Nodes, egress-lastige Nodes, Logging/Telemetry-Nodes
• 5) Retry-Stürme erkennen: Steigen Request-Raten, Fehlerraten und Retries gleichzeitig?
• 6) Kurzfristige Stabilisierung: Conntrack-Kapazität prüfen, Last verteilen, problematische Deployments drosseln
• 7) Nachhaltige Fixes: Connection Reuse, Retry-Policies, DNS-Strategie, Service-Architektur

Wie Sie Risiken reduzieren: Architektur- und Betriebspraktiken

Conntrack Full ist häufig ein Symptom dafür, dass ein Cluster an einem Engpass betrieben wird, ohne klare Guardrails. Gute Praxis ist, Conntrack als First-Class-Signal zu behandeln, ähnlich wie CPU, Memory und Disk.

• Monitoring: Conntrack-Nutzung und Drops als Metriken überwachen, Alerts mit sinnvollen Schwellenwerten
• Capacity Planning: Node-Typen und -Größen nach erwarteter Verbindungsrate dimensionieren, nicht nur nach CPU
• Traffic Engineering: Gateways/Ingress skalieren, Traffic gleichmäßig über Nodepools verteilen
• Load Tests realistisch: Tests müssen Verbindungsraten und Retry-Verhalten abbilden, nicht nur Throughput
• Change Safety: kube-proxy-Moduswechsel (iptables ↔ IPVS) und CNI-Änderungen wie risikoreiche Netzwerk-Changes behandeln

Warum „Conntrack Full“ oft mit DNS und Service Discovery verwechselt wird

DNS ist ein häufiger Kollateralschaden: Wenn Conntrack voll ist, können UDP-Flows (DNS-Anfragen) droppen oder nicht sauber zugeordnet werden. Dann wirkt es so, als sei CoreDNS kaputt, obwohl die Ursache am Node liegt. Umgekehrt kann eine DNS-Lastspitze auch Conntrack füllen und dadurch weitere Services stören. Deshalb ist es sinnvoll, DNS getrennt zu testen: Namensauflösung (Layer 7) versus Port-Erreichbarkeit (Layer 4) versus reine IP-Konnektivität (Layer 3).

Outbound-Quellen für vertiefendes Verständnis

• kube-proxy Referenzdokumentation
• Kubernetes Services: Service-Typen und Datenpfade
• Netfilter/iptables und Conntrack: Offizielle Dokumentation
• DNS for Services and Pods: CoreDNS und Service Discovery
• Kubernetes: Hinweise zu iptables und Networking

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.