„Flaky“ CNI troubleshooten: L2-Issue vs. Policy-Issue trennen

Ein „flaky CNI troubleshooten“ gehört zu den unangenehmsten Aufgaben im Kubernetes-Betrieb: Die Symptome sind real (Timeouts, sporadische Verbindungsabbrüche, DNS-Fehler, „No route to host“), aber sie treten unzuverlässig auf, verschwinden nach einem Pod-Restart und tauchen später wieder auf. In solchen Situationen ist die wichtigste Fähigkeit nicht das Ausprobieren von Einzelmaßnahmen, sondern die saubere Trennung zweier Fehlerklassen: Handelt es sich um ein L2-Issue (Bridging-, ARP/ND-, MTU-/Encapsulation-, MAC-Flapping- oder BUM-Effekte) oder um ein Policy-Issue (NetworkPolicy, eBPF-/iptables-Regeln, Security Groups, Service Mesh, Default Deny, asymmetrische Durchsetzung)? Beide Klassen können identische L7-Symptome erzeugen, erfordern aber völlig andere Beweise und Mitigations. Wer die Unterscheidung systematisch trifft, verkürzt Incident-Dauer, verhindert unnötige Rollbacks und reduziert das Risiko, dass „Fixes“ nur Nebenwirkungen kaschieren. Dieser Artikel zeigt ein praxistaugliches Vorgehen, um flakiges CNI-Verhalten reproduzierbar zu analysieren, klare Hypothesen zu bilden und evidenzbasiert zwischen L2- und Policy-Ursachen zu entscheiden.

Was „flaky“ im CNI-Kontext wirklich bedeutet

„Flaky“ ist kein präziser technischer Begriff, aber ein verlässliches Muster: Das System ist nicht dauerhaft down, sondern schwankt zwischen „funktioniert“ und „funktioniert nicht“. Diese Schwankung entsteht typischerweise durch zeitabhängige Zustände (Caches, Tables, Conntrack), dynamische Updates (Policy-Rollouts, Endpoint-Churn), oder pfadabhängige Effekte (ECMP, Overlays, Node-spezifische Hotspots). Gerade CNIs verbinden mehrere Ebenen: Pod-Netznamespace, veth, Bridge oder eBPF, Overlay oder Routing, Service-Mechanik (kube-proxy/EBPF), Policies und oft Cloud-Integration. Daher lohnt sich ein stabiler Bezug auf offizielle Grundlagen zu Kubernetes-Networking und CNI, um die richtigen „Fixpunkte“ im System zu kennen: Kubernetes Networking-Konzepte und die CNI-Spezifikation.

• Zeitabhängig: Fehler treten nach 5–30 Minuten auf (Cache-Expiry, Policy-Propagation, Conntrack-Pressure).
• Scope-spezifisch: nur bestimmte Nodes, Namespaces, AZs oder Service-Paare betroffen.
• Last-abhängig: p99-Latenz kippt, während p50 stabil bleibt; unter Stress reproduzierbarer.

Die Kernfrage: L2-Issue oder Policy-Issue?

Beide Fehlerklassen sind in Kubernetes plausibel, aber sie verhalten sich unterschiedlich. Ein L2-Issue beeinflusst typischerweise Zustellung, Neighbor-Resolution, MTU und lokale Switching-Mechanik. Ein Policy-Issue beeinflusst, ob Pakete überhaupt passieren dürfen, oft abhängig von Labels, Ports, Protokollen, Identitäten oder Richtung (ingress/egress). Das Entscheidende: L2-Probleme erzeugen häufig „Zufall“ durch Pfad- oder Timing-Effekte; Policy-Probleme erzeugen häufig „Logik“ durch deterministische Regeln, die aber wegen dynamischer Updates oder inkonsistenter Durchsetzung wie Zufall wirken können.

• L2-Issue: Paketverlust, Jitter, MTU/Fragmentierung, ARP/ND-Peaks, MAC-Flapping, BUM-Flooding.
• Policy-Issue: Drop durch NetworkPolicy/Firewall/eBPF/iptables, Default Deny, falsche Label-Selector, Richtung verwechselt.
• Hybrid-Fälle: Policy-Update triggert CPU/Queueing im Datenpfad, was wie L2-Loss aussieht; oder L2-Instabilität führt zu Retries, die Policy-Limits treffen.

Ein OSI-orientiertes Triage-Framework für CNIs

Ein schneller Weg aus dem Chaos ist eine konsequente Schichtenlogik: Erst klären, auf welcher Ebene das erste messbare Symptom auftritt. Das ist keine akademische Übung, sondern eine Priorisierung: Wenn bereits Connect-Time und TCP-Retransmits kippen, ist es selten ein reines L7-Problem. Wenn ausschließlich bestimmte Ports/Namespaces blockieren, ist Policy wahrscheinlicher. Als Rahmen kann das OSI-Modell dienen, ohne dass man jedes Detail „auswendig“ braucht.

• Layer 2/3 Signale: ARP/ND-Rate, Neighbor-Table-Instabilität, MTU-Indizien, Node-spezifische Drops.
• Layer 4 Signale: Connect-Time, TCP Retransmissions, SYN/SYN-ACK-Anomalien, RST/Timeout-Muster.
• Layer 7 Signale: HTTP/gRPC-Timeouts, DNS-Fehler, „upstream connect error“, mTLS-Handshake-Probleme.

Typische L2-Ursachen bei „flaky“ CNI

L2-Effekte tauchen besonders häufig auf, wenn das CNI auf Bridge-Mechanik basiert, wenn Overlays im Spiel sind oder wenn Endpunkt-Churn hoch ist. Viele Cluster sehen L2-Probleme nicht als „L2“, sondern als sporadische App-Timeouts. Die folgenden Ursachen sind in der Praxis besonders relevant.

ARP/ND-Pressure und Neighbor-Instabilität

Hoher Pod-Churn (Deployments, Autoscaling, Rescheduling) erzeugt viele neue Neighbor-Auflösungen. Wenn Neighbor-Tables überlaufen, Einträge schnell veralten oder ICMP/ND-Signale ungünstig gefiltert werden, entstehen intermittente Erreichbarkeitsprobleme. Grundlagen: RFC 826 (ARP) und RFC 4861 (IPv6 Neighbor Discovery).

• Symptom: kurze Brownouts nach Rollouts; einzelne Pods „hängen“ beim ersten Request.
• Beweisrichtung: ARP/ND-Spikes korrelieren zeitlich mit Latenz-/Timeout-Spikes.
• Mitigation-Idee: Rollouts staffeln, Connection Reuse erhöhen, Churn reduzieren.

MTU-/Encapsulation-Probleme in Overlays

Overlays (z. B. VXLAN) fügen Header hinzu. Wenn die effektive MTU nicht passt, brechen große Pakete eher als kleine. Das wirkt „flaky“, weil kleine Payloads oder kurze Antworten funktionieren, während bestimmte Requests (z. B. große gRPC-Messages, TLS-Zertifikatsketten, HTTP2-Frames) scheitern. VXLAN ist in RFC 7348 beschrieben.

${\mathrm{MTU}}_{\mathrm{eff}}={\mathrm{MTU}}_{\mathrm{path}}–O_{\mathrm{encap}}$

• Symptom: „Ping geht, App nicht“; Retransmits steigen; p99 explodiert.
• Beweisrichtung: Fehler treten bei größeren Payloads häufiger auf, node-/pfadabhängig.
• Mitigation-Idee: MTU end-to-end verifizieren, MSS-Clamping nur bewusst einsetzen, Encapsulation-Schichten reduzieren.

MAC-Flapping, Unknown-Unicast und BUM-Effekte

Bei Bridge-basierten Datenpfaden können Fehlkonfigurationen (Bonding/Bridging), Loops oder instabile Endpunkte MAC-Learning stören. Unknown-Unicast wird dann geflutet, was CPU/Queues belastet und Pakete „zufällig“ verzögert oder verwirft. In Overlays kann BUM-Verkehr zusätzlich repliziert werden, wodurch der Effekt größer wird.

• Symptom: Intermittente Drops, die sich über mehrere Services ziehen; oft node-spezifische Hotspots.
• Beweisrichtung: starke Last im Host-Netzwerkpfad (SoftIRQ), gleichzeitig keine klare Policy-Änderung.
• Mitigation-Idee: Verdächtige Nodes isolieren, Workloads verschieben, Bridge-/Bonding-Setups prüfen.

Typische Policy-Ursachen bei „flaky“ CNI

Policy-Probleme wirken häufig deterministisch – aber sie können flaky erscheinen, wenn Policies asynchron ausgerollt werden, wenn mehrere Ebenen greifen (NetworkPolicy + Cloud Security Groups + Service Mesh) oder wenn Stateful Mechanismen (Conntrack) alte Zustände weiterwirken. Besonders in Kubernetes ist die Kombination aus dynamischen Labels, Default Deny und „aus Versehen fehlenden“ egress-Regeln ein häufiger Auslöser.

NetworkPolicy: Selector-Logik und Default Deny

NetworkPolicies sind deklarativ und labelbasiert. Ein kleiner Label-Fehler, ein fehlender NamespaceSelector oder eine vergessene egress-Regel kann einzelne Flows blockieren. „Flaky“ wird es, wenn nicht alle Pods dieselben Labels tragen, wenn Deployments gemischt sind oder wenn Policy-Enforcement nicht überall gleich schnell greift. Eine gute Basis ist die offizielle Dokumentation zu Kubernetes NetworkPolicies.

• Symptom: Nur bestimmte Pods oder nur ein Teil der Requests scheitert (z. B. nur von neu gestarteten Pods).
• Beweisrichtung: Fehler hängt an Labels/Namespaces/Ports; Scope ist logisch (nicht topologisch).
• Mitigation-Idee: Policy-Änderungen rückgängig, Labels vereinheitlichen, „deny-by-default“ bewusst und vollständig machen.

Asymmetrische Policies und State: Conntrack und Richtungsfehler

Viele Policy-Implementierungen sind stateful oder interagieren mit stateful Komponenten. Wenn Rückpakete nicht erlaubt sind, wenn NAT/Service-Pfade anders laufen als erwartet oder wenn conntrack unter Druck steht, kann Verhalten unstet werden. Dann sieht es so aus, als ob „manchmal“ etwas erlaubt ist – tatsächlich ist es ein Zustandsartefakt.

• Symptom: Verbindungen klappen nach Retry oder nach kurzer Zeit wieder; bestehende Verbindungen ok, neue brechen.
• Beweisrichtung: Connect-Time/Handshake betroffen, aber Paketverlust-Metriken sind nicht dominant.
• Mitigation-Idee: Zustandsdruck reduzieren (Retries begrenzen, Connection Reuse), Policy-Richtung prüfen (ingress/egress), Service-Pfad verstehen.

Mehrschichtige Durchsetzung: CNI + Cloud + Service Mesh

In der Praxis wirken oft mehrere Mechanismen gleichzeitig: NetworkPolicy im Cluster, Security Groups/NSGs in der Cloud, und mTLS/AuthorizationPolicies im Service Mesh. „Flaky“ entsteht, wenn eine Ebene inkonsistent ist oder wenn Traffic teils über Sidecars, teils ohne Sidecars läuft (gemischte Mesh-Abdeckung). Für eBPF-orientierte CNIs und deren Policy-/Service-Datenpfad sind die Dokumentationen von Cilium und für policy-orientiertes Routing Calico hilfreich.

• Symptom: Nur mTLS-Pfade betroffen, oder nur Traffic über bestimmte Gateways/Ingresses.
• Beweisrichtung: Fehler hängt an Identitäten/Policies, nicht an Node-Topologie.
• Mitigation-Idee: Policy-Ebenen explizit auflisten, Reihenfolge klären, Scope pro Ebene testen.

Das schnellste Unterscheidungsmerkmal: Scope – topologisch oder logisch?

Ein sehr praktischer Hebel ist die Art des Scopes. L2-Issues sind häufig topologisch: bestimmte Nodes, Racks, AZs, Pfade. Policy-Issues sind häufig logisch: bestimmte Namespaces, Labels, Ports, Identitäten. Natürlich gibt es Ausnahmen, aber als erste Hypothese ist diese Trennung extrem effektiv.

• Topologischer Scope (L2 wahrscheinlicher): „Nur Nodepool A“, „nur AZ-2“, „nur bestimmte Hosts“.
• Logischer Scope (Policy wahrscheinlicher): „Nur Namespace X“, „nur Pods mit Label app=foo“, „nur Port 5432“.
• Gemischt: Wenn logischer Scope nur auf bestimmten Nodes auftritt, sind Desync oder Update-Probleme naheliegend.

Ein praxistauglicher Diagnose-Workflow für flakiges CNI

Der folgende Workflow ist so aufgebaut, dass er mit wenig Vorwissen startet, schnell Evidenz sammelt und dann gezielt vertieft. Wichtig ist, nicht „alles gleichzeitig“ zu ändern: Jede Maßnahme sollte eine Hypothese testen.

Schritt 1: Reproduzierbarkeit erhöhen, ohne das System zu zerstören

• Minimaler Testfall: ein Pod als Client, ein Pod als Server, definierter Port, definierte Payload-Größe.
• Vergleichstests: innerhalb desselben Nodes vs. cross-node; innerhalb desselben Namespace vs. cross-namespace.
• Payload variieren: klein vs. groß (MTU-Indiz), kurz vs. lang laufende Verbindung (State-Indiz).

Schritt 2: Erste Evidenz über Transport-Indikatoren

Transport-Indikatoren trennen „Drop/Queueing“ von „Blocked“. TCP-Retransmissions und Connect-Time sind oft schneller aussagekräftig als reine Applikationslogs. TCP-Grundlagen sind in RFC 9293 beschrieben.

• Retransmits hoch: spricht eher für Drops/Queueing/MTU (L2/L3).
• Retransmits normal, aber Verbindungen scheitern: spricht eher für Policy/Filter oder Routenfehler.
• p99 steigt stärker als p50: spricht für Queueing/Hotspots oder intermittente Blockaden.

Schritt 3: Policy-Schnellcheck (logische Ursachen ausschließen)

• NetworkPolicy-Inventar: Welche Policies gelten im Namespace? Gibt es Default Deny?
• Label-Konsistenz: Haben alle Pods die erwarteten Labels? Gibt es alte ReplicaSets?
• Egress nicht vergessen: DNS/Metadata/API-Calls benötigen oft egress; fehlender egress wirkt flaky.

Schritt 4: L2-Schnellcheck (topologische Ursachen ausschließen)

• Node-Korrelation: Häufen sich Fehler auf bestimmten Nodes? Hilft Rescheduling reproduzierbar?
• Churn-Korrelation: Tritt es nach Deployments/Autoscaling auf?
• MTU-Indiz: Scheitern große Payloads häufiger? Gibt es Overlay-Encapsulation?

Runbook-Mitigation: Stabilisieren, ohne Root Cause zu verlieren

Bei flakigen CNIs ist es verführerisch, „mehr Timeouts“ oder „mehr Retries“ einzubauen. Das stabilisiert kurzfristig, kann aber die Ursache verschleiern und sogar verschlimmern (Retry-Stürme). Besser sind reversible, evidenzfreundliche Maßnahmen.

• Rollouts staffeln/pausieren: reduziert Churn und Neighbor-Pressure; verbessert Signalqualität.
• Retries begrenzen: Backoff + Jitter, Retry-Budgets; verhindert positive Feedback-Loops.
• Workloads gezielt verschieben: wenn topologisch, dann Rescheduling aus Hotspots heraus.
• Policy-Änderungen versionieren: schnelle Rollbacks ermöglichen; „kleine“ Selector-Fehler sind häufig.
• MTU bewusst behandeln: nicht „blind“ clampen; erst Pfade verstehen, dann korrigieren.

Observability: Welche Signale die Trennung L2 vs. Policy erleichtern

Ohne passende Telemetrie bleibt die Unterscheidung ein Ratespiel. Ziel ist nicht maximale Datenmenge, sondern die richtigen Dimensionen: Node, Namespace, Service-Paar, Richtung, und Phasen (Connect/TLS/HTTP). Für standardisierte Instrumentierung ist OpenTelemetry eine sinnvolle Basis.

• Transport-Metriken: Connect-Time p95/p99, Retransmits, Drops/Errors am Node-Netzwerkpfad.
• Policy-Metriken/Events: Policy-Updates, Deny-Counter, Audit-Logs (je nach Implementierung).
• Topologie-Dimensionen: Nodepool/AZ/Rack-Gruppe, um L2-Hotspots sichtbar zu machen.
• Logik-Dimensionen: Namespace/Labels/ServiceAccount, um Policy-Scope sichtbar zu machen.

Typische Fehlinterpretationen, die Zeit kosten

• „DNS ist kaputt“: häufig ist DNS nur das erste Opfer (egress-policy, MTU, conntrack), nicht die Ursache.
• „Pod-Restart fixed it“: oft nur Cache/State reset; Root Cause bleibt aktiv.
• „Nur ein Service betroffen“: manchmal ist es ein gemeinsamer Pfad (Node, Gateway, Policy-Basis), der sich nur dort zuerst zeigt.
• „Mehr Retries helfen“: kann Drops/Queueing verstärken und aus Flaky einen Full-Outage machen.

Outbound-Referenzen für vertiefende Informationen

• Kubernetes: Networking-Konzepte (Services, DNS, Ingress)
• Kubernetes: NetworkPolicies (Konzept und Einsatz)
• CNI: Container Network Interface (Spezifikation)
• RFC 826: ARP (Neighbor-Resolution IPv4)
• RFC 4861: IPv6 Neighbor Discovery (ND)
• RFC 7348: VXLAN (Overlay-Kapselung)
• RFC 9293: TCP (Retransmissions und Transportverhalten)
• Cilium: Networking und Datenpfade (eBPF-orientiert)
• Calico: Networking-Überblick (Policy und Routing)
• OpenTelemetry: Observability-Standards für Metriken, Logs und Traces

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.