Bridge Networking vs. Routed CNI: L2-Effekte in Kubernetes

Bridge Networking vs. Routed CNI ist in Kubernetes kein akademischer Streit, sondern eine praktische Entscheidung, die Latenz, Fehlersuche, Skalierbarkeit und Sicherheitsmodell Ihrer Plattform messbar beeinflusst. Viele Teams merken das erst im Incident: Ein Node wird „noisy“, ARP- und Broadcast-Traffic steigt, Tail Latency kippt, oder einzelne Pods sind intermittierend nicht erreichbar. Häufig liegt die Ursache nicht im Code, sondern in L2-Effekten, die durch Bridging, Overlays oder ungünstige Neighbor-Resolution verstärkt werden. Gleichzeitig ist „routed CNI“ kein Allheilmittel: Routing-basierte Ansätze bringen eigene operative Anforderungen mit, etwa BGP, Route-Scale, Debugging auf L3-Ebene und ein anderes Zusammenspiel mit Cloud-Netzwerken. Wer als SRE oder Platform Engineer Kubernetes zuverlässig betreiben will, sollte deshalb verstehen, wie Bridge-basierte CNIs und routed CNIs Pakete tatsächlich bewegen, welche L2-Mechaniken dabei entstehen (oder vermieden werden) und wie sich diese Unterschiede in Observability-Signalen, Failure Domains und Runbooks niederschlagen. Dieser Artikel ordnet die beiden Ansätze ein, zeigt typische L2-Symptome in Kubernetes und liefert Kriterien, wann welche Architektur besser passt.

Grundlagen: Was Kubernetes beim Netzwerk überhaupt voraussetzt

Kubernetes schreibt kein konkretes Netzwerk-Produkt vor, aber es definiert Erwartungen: Jeder Pod bekommt eine eigene IP, Pods sollen untereinander erreichbar sein, und Services abstrahieren Endpunkte. Wie genau das umgesetzt wird, entscheidet das CNI-Plugin (Container Network Interface). CNI ist dabei nicht „das Netzwerk“, sondern eine Schnittstelle, über die Kubernetes (genauer: die Runtime) Netzwerke für Container/Pods konfiguriert. Eine gute Einstiegsebene sind die offiziellen Kubernetes-Konzepte zu Networking unter Services, Networking and Ingress sowie die CNI-Spezifikation unter CNI (Container Network Interface).

• Pod-IP-Modell: Pods sind „first-class“ IP-Endpunkte; NAT zwischen Pods ist nicht die Standardannahme.
• Service-Abstraktion: ClusterIP/NodePort/LoadBalancer bilden virtuelle Ziele auf Pod-Endpunkte ab.
• NetworkPolicy: optionale, CNI-abhängige Durchsetzung von L3/L4-Regeln (und teilweise L7 über Zusatzkomponenten).

Begriffe klären: Bridge Networking, Overlay und routed CNI

In der Praxis ist „Bridge Networking“ eine Familie von Designs, bei denen Pods an eine Linux Bridge (oder einen virtuellen Switch) auf dem Node angeschlossen werden. „Overlay“ ist häufig damit kombiniert: Pod-Traffic wird in ein zusätzliches Tunnel-Format gekapselt (z. B. VXLAN), um Pod-IP-Räume über Node-Grenzen hinweg zu transportieren. „Routed CNI“ meint dagegen Designs, bei denen Pod-Netze per Routing verteilt werden: Der Datenpfad folgt L3-Routen statt L2-Flooding, und Cross-Node-Konnektivität entsteht über geroutete Pfade (häufig mit BGP oder cloud-nativen Routen).

• Bridge (L2 lokal): Pods hängen an einer Bridge; Forwarding passiert über MAC-Lernen und lokale L2-Mechanik.
• Bridge + Overlay (Cross-Node): Bridge lokal, Cross-Node via Tunnel/Encapsulation; L2-/BUM-Effekte können über das Overlay sichtbar werden.
• Routed CNI (L3 Ende-zu-Ende): Pod-IP-Routen werden verteilt; Cross-Node folgt L3-Routing, Broadcast-Domänen werden minimiert.

Bridge Networking im Node: Was passiert wirklich?

Bei Bridge-basierten Designs wird für Pods häufig ein veth-Paar erstellt: Ein Ende liegt im Pod-Netznamespace, das andere Ende im Host-Netznamespace und wird an die Bridge angeschlossen. Die Bridge verhält sich wie ein Switch: Sie lernt MAC-Adressen und leitet Frames entsprechend weiter. Diese lokale L2-Ebene ist sehr leistungsfähig, hat aber typische L2-Eigenschaften, die bei hoher Dynamik sichtbar werden können.

• MAC-Learning: Die Bridge merkt sich, welcher Port welche MAC hat. Bei hohem Pod-Churn steigt der Lern- und Aktualisierungsdruck.
• Broadcast/ARP lokal: ARP-Requests werden innerhalb des Node-Segments verteilt; bei vielen Peers kann das CPU und Queues belasten.
• Interaktion mit iptables/eBPF: Services, NAT und Policies werden oft zusätzlich im Host realisiert, wodurch sich der Pfad verlängert.

ARP als Mechanik ist in RFC 826 beschrieben; für IPv6 Neighbor Discovery (ND) ist RFC 4861 relevant.

Overlay über Bridge: Warum L2-Effekte „größer“ wirken können

Viele Cluster nutzen Overlays, um Pod-IP-Räume über Nodes hinweg zu verbinden, ohne das Underlay-Netz zu verändern. Ein typisches Muster: Pod zu Pod auf demselben Node geht über die Bridge, Pod zu Pod auf unterschiedlichen Nodes geht zusätzlich durch eine Tunnelkapselung. Das ist operativ bequem, kann aber L2-Effekte verstärken, wenn BUM-Verkehr (Broadcast/Unknown-Unicast/Multicast) oder Neighbor-Resolution in große Skalen wächst. Zudem bringt Encapsulation MTU-Fragen mit sich, die sich als „intermittent“ Timeouts in höheren Schichten zeigen.

MTU und Kapselung als wiederkehrender Stolperstein

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

Wenn MTU_eff zu klein ist, drohen Fragmentierung oder Drops. Typische Symptome sind steigende TCP Retransmissions, höhere Connect-Time und ein starker p99-Anstieg. VXLAN als Overlay ist in RFC 7348 definiert.

Routed CNI: Wie Routing-basierte Pod-Netze funktionieren

Bei routed CNIs werden Pod-IP-Routen so verteilt, dass andere Nodes wissen, über welchen Next Hop ein bestimmtes Pod-Netz erreichbar ist. Häufig bekommt jeder Node einen eigenen Pod-CIDR-Block, und das Netzwerk (oder das CNI) sorgt dafür, dass diese CIDRs im Cluster bekannt sind. Der entscheidende Unterschied: Es gibt weniger Bedarf für L2-Flooding über Node-Grenzen. Cross-Node-Traffic folgt klaren L3-Pfaden, was Broadcast- und MAC-Learning-Pressure reduziert.

• Pro Node Pod-CIDR: ein definierter Adressblock, der auf dem Node „terminiert“.
• Routenverteilung: via BGP, via Cloud-Routen oder via zentralem Routing-Mechanismus des CNIs.
• Klare Pfade: Debugging orientiert sich an L3 (Route, Next Hop), weniger an L2 (MAC/ARP-Flapping).

Ein verbreitetes Beispiel für routed Networking ist Calico; als Einstieg eignet sich Calico Networking. Für eBPF-basierte Datenpfade und moderne Policy-/Service-Implementierungen ist Cilium Networking eine gute Referenz.

Welche L2-Effekte treten in Kubernetes typischerweise auf?

Unabhängig vom CNI sehen Plattformteams oft ähnliche Symptome, aber die Ursachen und Mitigations unterscheiden sich. Bridge- und Overlay-Setups machen L2-Effekte häufiger sichtbar, während routed Setups L2-Effekte eher lokal halten und stattdessen L3- und Route-Scale-Themen in den Vordergrund rücken.

ARP/ND Pressure und „Stale Neighbors“

• Bridge/Overlay: Mehr Neighbor-Resolution über vSwitch/Bridge; bei Churn steigt ARP/ND-Traffic spürbar.
• Routed CNI: ARP/ND ist stärker lokalisiert; Cross-Node benötigt weniger L2-Auflösung.
• Symptom: kurze Brownouts nach Rollouts, p99-Spikes, sporadische Timeouts ohne App-Änderung.

MAC-Flapping und Unknown-Unicast-Flooding

• Bridge/Overlay: Bei Fehlkonfigurationen (Bridging, Bonding, doppelte Interfaces) kann MAC-Flapping auftreten und Flooding verstärken.
• Routed CNI: MAC-Flapping ist meist weniger dominant; Pfade sind stärker an IP-Routen gebunden.
• Symptom: Intermittency, die „wandert“ oder nur einzelne Nodes trifft.

Tail Latency durch Queueing und SoftIRQ

• Bridge/Overlay: Zusätzliche Verarbeitung im Host (Bridge + Tunnel + ggf. iptables) erhöht die Wahrscheinlichkeit von CPU/Queueing-Hotspots.
• Routed CNI: kann effizienter sein, verschiebt aber Hotspots z. B. auf Routing- oder Policy-Mechanismen (abhängig von Implementierung).
• Symptom: p95/p99 steigen, p50 bleibt relativ stabil.

Service-Pfad nicht vergessen: kube-proxy, iptables, IPVS und eBPF

Die Frage „Bridge vs routed“ ist nur ein Teil des Datenpfads. Kubernetes Services können über kube-proxy mit iptables oder IPVS umgesetzt werden, oder über eBPF-Implementierungen (je nach CNI). Das beeinflusst L2-Effekte indirekt: Wenn Services viele neue Verbindungen erzeugen oder NAT/Conntrack stark belastet wird, steigt wiederum die Wahrscheinlichkeit von ARP/ND-Peaks und Tail-Latenz.

• iptables: flexibel, aber bei sehr großen Regelmengen kann Update- und Lookup-Overhead steigen.
• IPVS: performanteres L4-Load-Balancing, aber weiterhin conntrack- und Kernelpfad-Themen.
• eBPF: kann Pfade vereinfachen und Observability verbessern, bringt aber andere Betriebsanforderungen mit.

Für den Einstieg in Service Networking und kube-proxy ist die Kubernetes-Dokumentation zu Services hilfreich.

Debugging-Perspektive: Wie sich Incident-Triage unterscheidet

Im Incident zählt, wie schnell Sie Hypothesen validieren. Bridge-/Overlay-Ansätze führen oft zu Fragen wie „Sehen wir ARP/ND-Spikes? Gibt es MTU-Mismatches? Gibt es BUM-Flooding?“ Routed CNIs führen eher zu „Ist die Route verteilt? Ist der Next Hop erreichbar? Gibt es Route-Leaks oder fehlende Präfixe?“ Beide brauchen Telemetrie, aber unterschiedliche Schwerpunkte.

Triage-Hinweise bei Bridge/Overlay

• MTU-Indizien: Retransmits, große Responses brechen eher als kleine.
• Node-spezifische Hotspots: SoftIRQ/CPU-Netzwerkzeit steigt auf einzelnen Nodes.
• Churn-Korrelation: Peaks nach Deployments, Reschedules oder Autoscaling.

Triage-Hinweise bei routed CNI

• Route-Verfügbarkeit: Fehlt ein Pod-CIDR oder zeigt auf falschen Next Hop?
• Pfad-Determinismus: Probleme sind oft reproduzierbarer pro Route/Node.
• Scale-Fragen: Wie viele Routen/Policies werden verteilt, und wie schnell konvergiert das System?

Sicherheits- und Policy-Modell: L2-Isolation vs. Identity/Policy

Bridge-basierte Netze verleiten dazu, Isolation über L2-Segmente zu denken („VLAN pro Namespace“). In Kubernetes ist das oft nicht die beste Ebene: Workloads sind dynamisch, und Kommunikation hängt stärker an Identität (Service Accounts, mTLS, Policy) als an fester Netzlage. Routed CNIs passen häufig besser zu policygetriebenen Modellen, weil die Trennung ohnehin über L3 und Regeln erfolgt. Entscheidend ist: L2-Segmentierung kann Blast Radius begrenzen, ersetzt aber keine Autorisierung.

• NetworkPolicy: setzt L3/L4-Regeln durch, abhängig vom CNI (Umsetzung variiert).
• Service Mesh: ergänzt mTLS und feingranulare Identity-Policies, verändert aber Latenz- und Fehlerbilder.
• Pragmatisches Ziel: Segmentierung für Fault Domains, Policies für Zugriffskontrolle.

Performance und Skalierung: Worauf es in der Realität ankommt

Die Performancefrage ist selten „Bridge ist langsam“ oder „Routing ist schnell“. Viel häufiger sind es konkrete Engpässe: CPU im Host-Netzwerkpfad, MTU/Encapsulation, BUM-Peaks, conntrack-Last oder Route-Konvergenz. Für SREs ist besonders wichtig, nicht nur Durchschnittswerte zu betrachten, sondern Tail Latency und Burst-Verhalten.

Ein einfaches Modell für Tail-getriebene Degradation

$L_{\mathrm{p99}}\approx L_{\mathrm{base}}+L_{\mathrm{queue}}+L_{\mathrm{retry}}$

Bei Bridge/Overlay kann L_queue durch zusätzliche Verarbeitung (Bridge + Tunnel + NAT) steigen, während L_retry bei Drops/MTU-Problemen schnell eskaliert. Bei routed CNI sind L_queue und L_retry oft stärker an Routing-Konvergenz, Policy-Implementierung und Hostpfad gebunden.

Entscheidungskriterien: Wann Bridge sinnvoll ist – und wann routed CNI besser passt

Die Wahl sollte zu Ihrem Umfeld passen: Underlay-Fähigkeiten, Cloud-Constraints, Team-Skills, Compliance und SLOs. Eine gute Entscheidung basiert auf Failure Domains und operativer Beherrschbarkeit, nicht auf „Default-Empfehlungen“.

Bridge/Overlay ist oft sinnvoll, wenn

• Underlay nicht anpassbar ist: Sie können keine Routen verteilen (z. B. restriktive Netzvorgaben), brauchen aber schnell funktionierendes Pod-to-Pod.
• Time-to-Value zählt: einfache Inbetriebnahme ist wichtiger als maximale Transparenz.
• Cluster-Größe moderat bleibt: Churn und Endpunktzahl bleiben in einem Bereich, in dem ARP/ND/BUM nicht dominant wird.

Routed CNI ist oft sinnvoll, wenn

• Skalierung und Stabilität priorisiert sind: Sie wollen Broadcast-Domänen minimieren und Pfade deterministischer machen.
• Sie klare Fault Domains brauchen: Routing-Grenzen erleichtern Scope-Eingrenzung und Mitigation.
• Sie Netz- und Plattformbetrieb integrieren können: BGP oder Cloud-Routen sind organisatorisch beherrschbar.

Mitigation und Best Practices: L2-Effekte in Kubernetes reduzieren

Unabhängig vom CNI lassen sich viele Probleme entschärfen, wenn Sie Churn, MTU und Observability bewusst behandeln. Die wirksamsten Maßnahmen sind oft betrieblich und architektonisch – nicht „mehr Retries“ oder „größere Timeouts“.

• Rollouts staffeln: reduziert gleichzeitige Neighbor-Resolution und verhindert ARP/ND-Peaks.
• Connection Reuse fördern: Keep-Alive/Pooling reduziert neue Verbindungen und damit ARP-Last.
• MTU-End-to-End verifizieren: besonders bei Overlays und bei Hybridpfaden (Ingress/Egress, Peering, VPN).
• Retries disziplinieren: Backoff + Jitter, Retry-Budgets, um positive Feedback-Loops zu vermeiden.
• Telemetrie segmentieren: nach Node, Zone, Namespace, Service-Paar (Source→Destination) und Phase (Connect/TLS/HTTP).

Für Observability-Standards in verteilten Systemen ist OpenTelemetry eine verbreitete Grundlage.

Outbound-Referenzen für vertiefende Informationen

• Kubernetes: Services, Networking and Ingress
• Kubernetes: Service-Konzepte und Datenpfade
• CNI-Spezifikation: Container Network Interface
• RFC 826: ARP – Neighbor Resolution in IPv4
• RFC 4861: IPv6 Neighbor Discovery (ND)
• RFC 7348: VXLAN – Overlay-Kapselung
• Calico: Networking-Überblick (routed und policy-orientiert)
• Cilium: Networking und Datenpfade (eBPF-basiert)
• OpenTelemetry: Standardisierte Observability

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.