Conntrack-Table voll auf Kubernetes-Nodes: Symptome und Recovery

Wenn die Conntrack-Table voll auf Kubernetes-Nodes läuft, wirkt das in der Praxis wie ein „unsichtbarer“ Netzwerkausfall: Services verlieren sporadisch Verbindungen, DNS wirkt flaky, Outbound-Calls timeouten, und selbst interne Cluster-Kommunikation kann instabil werden. Das Problem trifft Plattform-Teams oft überraschend, weil CPU und Memory der Pods scheinbar in Ordnung sind – und trotzdem steigen Error Rate und Tail Latency abrupt an. Ursache ist meist nicht „Kubernetes an sich“, sondern der Linux-Kernel: Viele Kubernetes-Setups nutzen iptables/nftables, NAT (SNAT/Masquerade) und stateful Connection Tracking (conntrack). Jede neue Verbindung belegt einen Eintrag in der Conntrack-Tabelle. Wenn die maximale Größe erreicht ist oder die Table unter Druck gerät (z. B. durch Traffic-Spikes, hohe Connection-Churn-Raten, kurze Timeouts oder falsch dimensionierte Node-Kapazität), kann der Node neue Flows nicht mehr zuverlässig tracken. Die Folgen sind hart: Paketdrops, fehlgeschlagene Handshakes, unerklärliche Resets und ein Incident, der sich im Monitoring wie ein Mischbild aus Netzwerk- und Applikationsfehlern darstellt. In diesem Artikel lernen Sie, welche Symptome typisch sind, wie Sie Conntrack-Exhaustion nachweisen, welche Sofortmaßnahmen im Incident wirklich helfen und wie Sie Ihr Kubernetes-Cluster so designen, dass eine volle Conntrack-Table nicht mehr zum wiederkehrenden Klassiker wird.

Conntrack in Kubernetes: Warum es überhaupt eine Tabelle gibt

Conntrack ist Teil des Linux-Netfilter-Subsystems. Es verfolgt Verbindungen (States) für Protokolle wie TCP und UDP, damit stateful Firewall-Regeln, NAT und bestimmte Load-Balancing-Funktionen korrekt arbeiten können. In Kubernetes kommt conntrack besonders häufig ins Spiel, weil:

• Service-Traffic oft über iptables/nftables-Regeln umgesetzt wird (z. B. kube-proxy im iptables-Modus).
• SNAT/Masquerade bei Pod-Egress oder bestimmten Cluster-Konfigurationen genutzt wird.
• NodePort/LoadBalancer-Pfadanteile conntrack-relevant sein können.
• CNI-Plugins je nach Modus (iptables, eBPF, Overlay) unterschiedlich stark conntrack beanspruchen.

Wichtig: Conntrack ist begrenzt. Die Tabelle hat eine maximale Anzahl an Einträgen und benötigt Speicher. Wenn sie voll ist, kann der Kernel neue Verbindungen nicht sauber verfolgen – und genau das führt zu „Random“-Fehlern, die sich nicht sauber einem Service zuordnen lassen.

Was bedeutet „Conntrack-Table voll“ technisch?

„Voll“ heißt in der Praxis: Die Zahl aktiver conntrack entries nähert sich dem Limit (nf_conntrack_max) oder erreicht es. Dann treten Drops und Fehler auf, weil neue Flows keinen Eintrag mehr bekommen. Häufig ist das nicht nur ein statischer Grenzwert, sondern ein dynamisches Problem: Ein kurzer Spike kann die Table füllen, Einträge bleiben aufgrund von Timeouts bestehen, und der Node erholt sich erst verzögert.

Typische Ursachen im Kubernetes-Alltag

• Traffic-Spikes (Deployments, Backfills, Events, plötzliche Last von außen).
• Hohe Connection-Churn durch fehlendes Pooling (HTTP/1.1 ohne Keepalive, aggressive gRPC-Reconnects).
• DNS-Last (viele UDP-Queries, kurze TTLs, fehlerhafte Resolver-Strategien).
• NAT-heavy Egress (Masquerade für viele Pods über Node-IP).
• Load-Balancer/NodePort-Pfade, die pro Connection viele conntrack states erzeugen.
• Zu kleine conntrack table im Verhältnis zur Node-Größe und zum Workload-Profil.

Symptome: Wie sich conntrack exhaustion in Produktion anfühlt

Conntrack-Probleme sind tückisch, weil sie „schmutzige“ Symptome erzeugen. Sie sehen selten eine saubere Fehlermeldung in einem einzelnen Service, sondern ein Muster über viele Komponenten.

Netzwerk- und Transport-Symptome

• Sporadische TCP-Connect-Failures (Timeouts, SYN-Retries, sporadische Resets).
• Erhöhte Retransmissions und steigende Tail Latency (p95/p99).
• UDP-Drops (z. B. DNS wirkt „flaky“ oder Responses fehlen).
• „No route to host“ / „Destination unreachable“ in Logs, ohne dass Routing wirklich kaputt ist.

Applikationssymptome, die leicht in die Irre führen

• gRPC UNAVAILABLE und DEADLINE_EXCEEDED häufen sich, besonders bei hoher Parallelität.
• HTTP 502/503/504 an Proxies/Ingress, obwohl Backends „eigentlich laufen“.
• Fehler über viele Ziele: nicht nur ein Downstream, sondern mehrere externe und interne Abhängigkeiten.
• Intermittent Pattern: kurze Phasen „alles rot“, dann wieder scheinbar normal.

Cluster-Symptome auf Node-Ebene

• Nur einzelne Nodes betroffen: Pods auf bestimmten Nodes haben Fehler, andere sind stabil.
• Pod-Restarts wirken kurzfristig hilfreich, weil Verbindungen abbrechen und conntrack entries ablaufen – das Problem kommt aber wieder.
• Node wird „unzuverlässig“: Readiness-/Liveness-Probes schlagen sporadisch fehl.

Nachweis: Wie Sie sicher bestätigen, dass conntrack die Ursache ist

Für Incident-Triage ist der Nachweis entscheidend, sonst verlieren Teams Zeit in falschen Richtungen (DNS, Applikationsbugs, „das Netzwerk“). Ziel ist eine klare Korrelation: conntrack usage hoch + Drops/Fehler hoch + betroffene Nodes.

Conntrack-Metriken und Kernel-Indikatoren

• Aktuelle Anzahl Einträge (oft als nf_conntrack_count sichtbar).
• Maximalwert (nf_conntrack_max).
• Kernel-Logs: Meldungen, dass die conntrack table voll ist (häufig im Kernel-Ringbuffer sichtbar).
• Drops/Invalids in netfilter/conntrack-Zählern (je nach Tooling).

Für die Grundlagen lohnt sich die Netfilter-Dokumentation, weil sie die conntrack-Mechanik, Statefulness und NAT sauber einordnet.

Korrelation mit Service-Symptomen

• Mapping Node → Fehler: Welche Pods liefen auf welchen Nodes, als die Fehler begannen?
• Connect-Latenz: Steigt die TCP-connect time oder „time to first byte“ gleichzeitig auf den betroffenen Nodes?
• DNS-Fehler: Steigen NXDOMAIN/Timeouts oder „SERVFAIL“ parallel zur conntrack usage?

Der stärkste Beweis ist fast immer die Node-Segmentierung: Wenn ein Rollout, eine DaemonSet-Änderung oder ein Nodepool mit anderer conntrack-Konfiguration exakt die betroffenen Nodes erklärt, ist die Ursache sehr wahrscheinlich gefunden.

Dimensionierung verstehen: Warum das Limit oft falsch gewählt ist

Viele Cluster laufen mit Default-Werten, die für kleine Nodes oder andere Workload-Profile gedacht waren. Für Dimensionierung ist weniger „Pods pro Node“ relevant als „gleichzeitige Verbindungen und Flows pro Node“ und deren Haltezeit (Timeouts). Ein einfaches Modell hilft, das Risiko abzuschätzen:

Ein grobes Kapazitätsmodell für conntrack

Wenn ein Node im Mittel C gleichzeitige aktive Verbindungen hält und zusätzlich durch UDP/DNS, Retries oder kurze Verbindungen ein „Flow-Burst“-Anteil B entsteht, dann sollte das conntrack-Limit mit ausreichender Reserve über C + B liegen. Als sehr vereinfachte Heuristik:

$\mathrm{nf\_conntrack\_max}>C+B\times \mathrm{SafetyFactor}$

Der SafetyFactor hängt davon ab, wie spiky Ihr Traffic ist (z. B. 2 bis 4 als Startpunkt). Entscheidend ist: Wenn Sie nur „genau passend“ dimensionieren, verlieren Sie beim nächsten Burst. Und wenn Ihre Timeouts zu lang sind, steigt C effektiv, weil Einträge länger belegt bleiben.

Recovery im Incident: Was Sie sofort tun können

Wenn die Conntrack-Table voll ist, brauchen Sie schnelle Maßnahmen, die das System wieder in einen stabilen Zustand bringen. Dabei gilt: Sie müssen entweder (a) den Druck reduzieren oder (b) die Kapazität erhöhen – idealerweise beides. Wichtig ist auch, nicht aus Versehen zu verschlimmern: „Mehr Retries“ oder „schnelleres Reconnect“ füllt conntrack häufig noch schneller.

Druck reduzieren: Verbindungserzeugung senken

• Retries drosseln: besonders bei Clients, Proxies und Libraries. Retry-Stürme sind ein conntrack-Beschleuniger.
• Parallelität begrenzen: Batch-Jobs, Worker, Backfills pausieren oder throttlen.
• Traffic umleiten: wenn möglich, Workloads auf weniger betroffene Nodepools shiften.
• DNS-Last reduzieren: Cache/TTL-Strategie prüfen, unnötige Re-Resolves stoppen.

Kapazität erhöhen: Node-seitig und infrastrukturell

• Nodepool skalieren: mehr Nodes verteilen Flows (sofern Traffic sich tatsächlich verteilt).
• Conntrack-Limit erhöhen: kurzfristig möglich, wenn genügend RAM vorhanden ist und die Umgebung das erlaubt.
• Problem-Nodes cordonen/drainen: um den Blast Radius zu reduzieren und Pods neu zu verteilen.

Das Drainen von Nodes ist ein legitimes Recovery-Mittel, wenn das Problem node-lokal ist. Dabei sollten Sie gleichzeitig die Ursache beheben, sonst kehrt das Problem nach der Umverteilung zurück.

Gezielte Reset-Strategien: Vorsicht bei „Conntrack flush“

Ein kompletter conntrack flush kann kurzfristig helfen, ist aber riskant: Er reißt existierende Verbindungen ab und kann Folgelast erzeugen (Reconnect-Sturm). Wenn Sie flushen, dann nur kontrolliert und bevorzugt für eng begrenzte Scopes. In vielen Umgebungen ist es sicherer, den Druck über Retry-Drosselung und Skalierung zu senken und Einträge über Timeouts auslaufen zu lassen.

Recovery-Checkliste: Stabilität verifizieren

• nf_conntrack_count sinkt unter eine sichere Schwelle und bleibt dort.
• Connect Errors und DNS-Timeouts normalisieren sich.
• p95/p99 fällt, insbesondere bei externen Abhängigkeiten.
• Retry-Rate bleibt niedrig (keine neue Lastverstärkung).

Prävention: So verhindern Sie volle Conntrack-Tabellen dauerhaft

Langfristige Stabilität entsteht durch eine Kombination aus richtiger Dimensionierung, sauberer Traffic-Architektur und bewusster Client-/Proxy-Konfiguration. Conntrack ist kein „einmaliger Bug“, sondern ein Kapazitäts- und Betriebsparameter.

Conntrack richtig dimensionieren und überwachen

• Alerts auf Auslastung: nicht erst bei 100 %, sondern früh (z. B. 70–85 %).
• Per-Node Dashboards: Aggregation verschleiert Hot Nodes.
• Baseline und Peak: messen Sie typische Peaks (Deployments, Cron-Spitzen) und dimensionieren Sie dafür.

Connection Churn reduzieren: Pooling und Keepalive als Standard

• HTTP Keepalive aktiv und korrekt einstellen (Connection Reuse).
• gRPC Channels stabil halten und Reconnect/Keepalive-Policies konsistent mit der Infrastruktur konfigurieren.
• Timeout-Hierarchie definieren: Client-Deadlines, Proxy-Timeouts, Backend-Timeouts sauber staffeln.

DNS-Verhalten stabilisieren

• Caching: Resolver- und Client-Caches sinnvoll nutzen, um Query-Stürme zu vermeiden.
• TTL-Strategie: zu niedrige TTLs erzeugen unnötige Last; zu hohe TTLs erschweren Failover.
• UDP vs. TCP DNS: verstehen, wann DNS über TCP fällt (z. B. große Antworten), was conntrack anders belastet.

Ein guter Einstieg in Kubernetes-spezifische Networking- und DNS-Aspekte ist die offizielle Dokumentation, z. B. über Kubernetes Services & Networking und DNS for Services and Pods.

NAT und Service-Pfade kritisch prüfen

Conntrack-Probleme eskalieren häufig dort, wo NAT oder stateful Regeln massiv genutzt werden. Prüfen Sie, ob Ihr Design unnötig viel SNAT auf Nodes erzwingt (z. B. durch Egress-Design) oder ob Service-Pfade mehr States erzeugen als nötig.

• Egress sharden: nicht alle Outbounds über dieselben Nodes/Interfaces.
• Node-local hotspots reduzieren: Workloads verteilen, Top Talkers identifizieren.
• LB/Proxy-Design: Timeouts und Connection Pools so wählen, dass keine künstliche Connection-Churn entsteht.

eBPF-basierte Datenpfade als Option: Weniger Abhängigkeit von iptables/conntrack

Je nach CNI und Betriebsmodell können eBPF-basierte Datenpfade bestimmte conntrack-Abhängigkeiten reduzieren oder Observability verbessern. Das ist keine „magische Lösung“, aber eine strategische Option, insbesondere wenn kube-proxy/iptables in Ihrem Profil zum Engpass wird. Informationen dazu finden Sie beispielsweise in der Dokumentation moderner eBPF-Netzwerkstacks wie Cilium.

Runbook für SRE/Platform: Schnelle Triage bei Verdacht auf conntrack

• Scope klären: nur einige Nodes betroffen? nur Outbound oder auch East-West?
• Per-Node conntrack usage prüfen: count vs. max, zeitlicher Verlauf.
• Top Talkers identifizieren: welche Pods/Namespaces erzeugen die meisten neuen Verbindungen?
• Retries/Timeouts prüfen: sind Clients aggressiver geworden (Release, Config Change)?
• Recovery wählen: Traffic drosseln, Nodes skalieren, problematische Nodes drainen, conntrack-Limit erhöhen (mit Bedacht).

Outbound-Links für vertiefende Informationen

• Netfilter Dokumentation: Conntrack, NAT und Kernel-Netzwerkgrundlagen
• Kubernetes Dokumentation: Services & Networking
• Kubernetes DNS: Services and Pods
• Cilium Dokumentation: eBPF Networking und Observability
• RFC 4787: NAT Behavioral Requirements (hilfreich für State-/Timeout-Verständnis)
• RFC 9293: TCP (für Timeout-, Retransmission- und Zustandsmodelle)

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.