Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

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).

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.

MTUeff = MTUpath – Oencap

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

Typische Fehlinterpretationen, die Zeit kosten

Outbound-Referenzen für vertiefende Informationen

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:

Lieferumfang:

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.

 

Exit mobile version