Software-defined Networking für Kubernetes
Datenströme steuern
Veröffentlicht in Ausgabe 03/2026 - PRAXIS
Ohne Software-defined Networking (SDN) lässt sich Kubernetes weder sinnvoll im Mehrmandantenbetrieb einsetzen noch dauerhaft skalierbar betreiben. Klassische Netzwerke auf Basis von VLANs scheiden dafür aus. Steht für einen Administrator absehbar ein Kubernetes-Cluster an, folgt daraus zwangsläufig die Frage nach dem passenden SDN-Ansatz und welcher davon den gewünschten Einsatzzweck abdeckt.
Die Architektur muss zum Tool passen
Mit Flannel [1], Calico [2] und Cilium [3] betrachten wir die derzeit bekanntesten Netzwerk-Plug-ins im Kubernetes-Ökosystem, die dazu dienen SDN aufzubauen. Trotz ihrer Unterschiede verbindet sie ein zentraler Aspekt: Alle drei sind CNI-konform und binden sich über dieselbe Schnittstelle an Kubernetes an. Diese Schnittstelle bleibt dabei bewusst neutral. Sie definiert lediglich, dass Pods miteinander kommunizieren können müssen, nicht jedoch, auf welchem technischen Weg dies geschieht.
Die drei Werkzeuge setzen dieses Grundprinzip unterschiedlich um. Flannel beschränkt sich auf reine Konnektivität und stellt sicher, dass jeder Pod jeden anderen Pod erreichen kann. Calico ergänzt dieses Modell um Routing-Logik und Sicherheitsregeln, die sich direkt aus Kubernetes-Objekten ableiten lassen. Cilium geht darüber hinaus und verlagert große Teile der Netzwerk- und Sicherheitslogik in den Kernel der Hostsysteme. Ziel ist es, Datenströme nicht nur zu transportieren, sondern sie inhaltlich zu erfassen und gezielt zu kontrollieren.
Ohne Software-defined Networking (SDN) lässt sich Kubernetes weder sinnvoll im Mehrmandantenbetrieb einsetzen noch dauerhaft skalierbar betreiben. Klassische Netzwerke auf Basis von VLANs scheiden dafür aus. Steht für einen Administrator absehbar ein Kubernetes-Cluster an, folgt daraus zwangsläufig die Frage nach dem passenden SDN-Ansatz und welcher davon den gewünschten Einsatzzweck abdeckt.
Die Architektur muss zum Tool passen
Mit Flannel [1], Calico [2] und Cilium [3] betrachten wir die derzeit bekanntesten Netzwerk-Plug-ins im Kubernetes-Ökosystem, die dazu dienen SDN aufzubauen. Trotz ihrer Unterschiede verbindet sie ein zentraler Aspekt: Alle drei sind CNI-konform und binden sich über dieselbe Schnittstelle an Kubernetes an. Diese Schnittstelle bleibt dabei bewusst neutral. Sie definiert lediglich, dass Pods miteinander kommunizieren können müssen, nicht jedoch, auf welchem technischen Weg dies geschieht.
Die drei Werkzeuge setzen dieses Grundprinzip unterschiedlich um. Flannel beschränkt sich auf reine Konnektivität und stellt sicher, dass jeder Pod jeden anderen Pod erreichen kann. Calico ergänzt dieses Modell um Routing-Logik und Sicherheitsregeln, die sich direkt aus Kubernetes-Objekten ableiten lassen. Cilium geht darüber hinaus und verlagert große Teile der Netzwerk- und Sicherheitslogik in den Kernel der Hostsysteme. Ziel ist es, Datenströme nicht nur zu transportieren, sondern sie inhaltlich zu erfassen und gezielt zu kontrollieren.
Dabei sollten Flannel, Calico und Cilium nicht als aufeinanderfolgende Entwicklungsstufen verstanden werden, bei denen eine Option zwangsläufig "moderner" oder "besser" wäre. Die Projekte stehen für unterschiedliche Architekturentscheidungen und adressieren unterschiedliche Anforderungen. Ein Vergleich einzelner Features greift daher zu kurz. Entscheidender ist, welches Betriebsmodell, welches Sicherheitsverständnis und welche Komplexität ein IT-Verantwortlicher im eigenen Cluster akzeptieren will.
IT-Administrator Sonderheft "Kubernetes"
Kubernetes auf einem Server einzuspielen ist ein Leichtes. Doch ohne passendes Infrastrukturdesign und ohne das notwendige Know-how für den Betrieb bleibt von den Erwartungen des IT-Teams nicht viel übrig: Reibungsloser Anwendungsbetrieb, nahtloses Skalieren und nicht zuletzt der Reduktion der IT-Kosten dank Kubernetes klappen nur mit klaren Vorgaben und tiefem Know-how in Sachen Container-Orchestrierung. All dies finden IT-Verantwortliche im neuen IT-Administrator Sonderheft rund um das Thema "Kubernetes – Design, Administration und Sicherheit optimieren".Den Einstieg in Kubernetes unterstützt das Autorenteam des IT-Administrator mit tiefem Know-how rund um die Designentscheidungen etwa beim Storage und im Netzwerk. Daneben stellen wir Überlegungen zu Hochverfügbarkeit und Sicherheit an. Steht die Kubernetes-Landschaft, blicken wir auf Fragen der Administration und Sicherheit. Hier zeigen verschiedene Beiträge Best Practices in Sachen Backup, Skalierung, Upgrades und Security. Den Abschluss bildet schließlich ein Kapitel rund um den Applikationsbetrieb. Wir zeigen, welche GUIs hier zur Verfügung stehen, wie Automatisierung umsetzbar ist und wie das Monitoring in Containers funktioniert.Das Sonderheft ist ab Ende April verfügbar und kostet für Abonnenten des IT-Administrator 24,90 Euro, für Nichtabonnenten werden 29,90 Euro fällig.
Flannel bietet einfache Konnektivität
Flannel gehört zu den ältesten und zugleich schlichtesten CNI-Plug-ins im Kubernetes-Umfeld. Das Projekt verfolgt einen klaren Fokus: Pods sollen sich clusterweit erreichen können, ohne dass der Administrator tief in die bestehende Netzwerkarchitektur eingreifen muss. Flannel verzichtet bewusst auf komplexe Steuerlogik und stellt stattdessen ein durchgängiges Pod-Netz bereit, das unabhängig von der physischen Topologie funktioniert.
Technisch setzt Flannel in den meisten Installationen auf ein Overlay-Netzwerk, typischerweise auf Basis von VXLAN. Jeder Knoten erhält ein eigenes Pod-Subnetz, aus dem die lokal laufenden Pods ihre IP-Adressen beziehen. Die Software kapselt den Verkehr zwischen diesen Subnetzen in VXLAN-Pakete und transportiert ihn über das bestehende Underlay-Netzwerk. Für die physische Infrastruktur bleibt dieser Verkehr weitgehend transparent. Switches und Router müssen lediglich IP-Pakete weiterleiten, ohne Pod-Adressen oder Kubernetes-spezifische Details zu berücksichtigen.
Diese Architektur erklärt einen Großteil der Attraktivität von Flannel. Der Admin muss weder das bestehende Netzwerk anpassen noch spezielle Routingprotokolle einführen oder die Infrastruktur eng mit Kubernetes verzahnen. Solange IP-Konnektivität zwischen den Knoten besteht, funktioniert auch Flannel. Gerade in einfachen Setups, Testumgebungen oder kleineren Clustern senkt dieser Ansatz die Einstiegshürde deutlich.
Bewusst reduzierte Steuerlogik
Flannel hält die Steuerlogik gezielt schlank. Das Werkzeug verteilt die Pod-Subnetze zentral, etwa über "etcd" oder das Kubernetes-API, und konfiguriert auf jedem Knoten automatisch die benötigten Tunnel-Endpunkte. Darüber hinaus trifft das Plug-in kaum eigene Entscheidungen. Network Policies implementiert es nicht, ebenso fehlt eine integrierte Sicherheitslogik. Aus Sicht von Kubernetes entsteht damit ein flaches Netzwerk, in dem jeder Pod jeden anderen Pod erreichen kann. Sicherheitsgrenzen lassen sich in solchen Umgebungen nur über externe Mechanismen abbilden, etwa über Firewalls außerhalb des Clusters oder zusätzliche Werkzeuge.
Neben VXLAN unterstützt Flannel auch alternative Backends, etwa Host-Gateway-Modelle, bei denen der Verkehr ohne Kapselung durch das Underlay-Netz fließt. Diese Varianten setzen allerdings voraus, dass das physische Netzwerk die notwendigen Routen kennt und verteilt. In der Praxis bleibt VXLAN die am häufigsten genutzte Option, da sie unabhängig von der vorhandenen Infrastruktur funktioniert und dem IT-Verantwortlichen konsistente Ergebnisse liefert.
Der Verzicht auf zusätzliche Funktionen wirkt sich direkt auf den Betrieb aus. Flannel erzeugt wenig Overhead, lässt sich vergleichsweise einfach analysieren und verhält sich im Fehlerfall vorhersehbar. Ist ein Pod nicht erreichbar, liegt die Ursache meist in grundlegenden Netzwerkproblemen oder in der Cluster-Konfiguration, nicht in komplexen Regelwerken oder verteilten Steuermechanismen – schlicht deshalb, weil Flannel diese nicht mitbringt. Für bestimmte Szenarien stellt das einen klaren Vorteil dar. Insbesondere Einsteiger im Kubernetes-Umfeld profitieren von der überschaubaren Komplexität.
Gleichzeitig markiert diese Einfachheit auch die Grenzen des Werkzeugs. In Umgebungen mit mehreren Mandanten, erhöhten Sicherheitsanforderungen oder dem Bedarf an fein granularer Traffic-kontrolle stößt Flannel konzeptionell an seine Grenzen. Das Netzwerk kennt weder Identitäten noch Rollen oder Richtlinien. Plattformen, die auf diese Abstraktionen angewiesen sind, können Flannel allenfalls als technisches Fundament nutzen, nicht jedoch als vollständige Infrastruktur. Der zusätzliche Aufwand durch ergänzende Komponenten fällt in solchen Szenarien entsprechend hoch aus.
Calico bietet Routing und Policies per BGP
Calico positioniert sich zwischen der bewusst minimalistischen Architektur von Flannel und stärker integrierten, kernelnahen Ansätzen moderner eBPF-basierter Werkzeuge. Das Projekt verfolgt das Ziel, Kubernetes-Netzwerke skalierbar, kontrollierbar und transparent zu gestalten, ohne zusätzliche Abstraktionsschichten einzuführen. Im Zentrum steht ein klarer Architekturgedanke: Pods erhalten reguläre IP-Adressen, und das Netzwerk behandelt diese Adressen möglichst wie klassische Endpunkte im Rechenzentrum.
Technisch verzichtet Calico in seiner klassischen Betriebsform auf ein Overlay-Netzwerk. Stattdessen nutzt es konsequent Layer-3-Routing, meist auf Basis von BGP. Jeder Knoten kündigt die Pod-IP-Adressen, die er hostet, aktiv per BGP im Netzwerk an. Andere Nodes übernehmen diese Routen und leiten den Traffic entsprechend weiter. Calico setzt dafür auf den BGP-Daemon BIRD. Die sonst bei VXLAN-Overlays übliche Paketkapselung entfällt. Der Datenpfad bleibt direkt, und der Netzwerkverkehr ähnelt stark dem klassischer IP-Infrastrukturen.
Diese Architekturentscheidung wirkt sich ganz unmittelbar auf Performance und Debugging aus. Pakete folgen klar definierten Routen, lassen sich mit etablierten Werkzeugen analysieren und unterliegen weniger zusätzlicher Verarbeitung. Gleichzeitig erfordert dieser Ansatz ein grundlegendes Verständnis von Routing. Entweder übernimmt Calico selbst das BGP-Peering zwischen den Nodes, oder es bindet sich in ein bestehendes Routingsetup ein, etwa auf Basis von EVPN. In beiden Varianten wird das Pod-Netz für das Underlay sichtbar. Das erleichtert Skalierung und Fehlersuche, verlagert aber auch Verantwortung auf die Netzwerkebene.
Netzwerkregeln als integraler Bestandteil
Ein zentrales Merkmal von Calico ist die konsequente Umsetzung von Network Policies. Das Werkzeug übersetzt die deklarativen Sicherheitsregeln aus Kubernetes in konkrete Filterregeln auf den einzelnen Knoten. Diese Regeln basieren auf Labels, Namespaces und IP-Adressen und erlauben es, Datenverkehr gezielt freizugeben oder zu blockieren. Aus einem flachen Netzwerk entsteht so ein kontrolliertes System mit klar definierten Kommunikationsbeziehungen. Für Plattformen mit Mehrmandantenbetrieb oder ausgeprägten Sicherheitszonen stellt dies einen wesentlichen Vorteil dar.
Calico setzt diese Policies traditionell über das Firewall-Framework "nftables" um. Der Datenverkehr durchläuft damit etablierte Pfade im Betriebssystem und im Linux-Kernel, was Vorhersehbarkeit und Stabilität fördert. Im Vergleich zu Overlay-Ansätzen steigt die Komplexität weniger im Netzwerk selbst, sondern stärker in der Pflege der Policy-Logik. Dieses Modell passt gut zu Kubernetes, setzt jedoch saubere Labels und konsistente Namenskonventionen voraus.
Etablierte Netzwerkarchitektur mit klarer Abgrenzung
Über den reinen Kubernetes-Einsatz hinaus versteht sich Calico als Netzwerkplattform für hybride Umgebungen. Virtuelle Maschinen, Bare-Metal-Systeme und Container lassen sich über dieselben Mechanismen anbinden. Diese Vielseitigkeit erklärt, warum Calico in vielen produktiven Clustern als Standardwerkzeug zum Einsatz kommt.
Der gewählte Mittelweg bringt jedoch auch klare Grenzen mit sich. Calico bleibt primär ein Netzwerk- und Policy-System. Tiefgehende Einblicke in Anwendungsprotokolle oder detaillierte Laufzeitanalysen gehören nicht zu seinem Funktionsumfang. Betreiber mit entsprechenden Anforderungen ergänzen Calico daher häufig um separate Werkzeuge für Observability und Analyse.
Calico steht damit für ein Netzwerkmodell, das die Konzepte von Kubernetes aufgreift, ohne deren Komplexität unnötig zu erhöhen. Es verbindet klassische Netzwerktechnik mit den Abstraktionen der Plattform und bietet Administratoren ein Werkzeug, das sich skalieren, nachvollziehen und stabil betreiben lässt.
Cilium mit eBPF als Netzwerk- und Sicherheitsmotor
Cilium unterscheidet sich grundlegend von Flannel und Calico, da es nicht versucht, bestehende Netzwerkmechanismen möglichst elegant nachzubilden. Stattdessen interpretiert es den Datenpfad neu. Das Projekt basiert vollständig auf eBPF und verlagert große Teile der Netzwerk-, Sicherheits- und Beobachtungslogik direkt in den Linux-Kernel. Der Fokus verschiebt sich damit von der reinen Paketweiterleitung hin zu einer kontextbewussten Verarbeitung von Netzwerkverkehr aus Sicht der Plattform.
In klassischen SDN-Ansätzen wie bei Calico durchlaufen Pakete mehrere klar definierte Schichten. Virtuelle Schnittstellen, Routing, Paketfilter, Netzwerkbrücken und gegebenenfalls Overlay-Tunnel bilden dort das Rückgrat der Infrastruktur. Cilium umgeht große Teile dieses Pfads. eBPF-Programme docken an definierte Hook-Punkte im Kernel an und treffen dort Entscheidungen darüber, wie mit einem Paket oder einem Socket zu verfahren ist.
Auf diese Weise erfasst eBPF den Datenverkehr früher als Flannel oder Calico und verarbeitet ihn mit weniger Kontextwechseln sowie mit deutlich mehr Informationen über den verursachenden Prozess, den Container und den Kubernetes-Bezug.
Kontext als zentrales Steuerungsmerkmal
Im Kubernetes-Umfeld ergibt sich daraus ein wesentlicher Vorteil: Cilium betrachtet Netzwerkverkehr nicht primär als Verbindung zwischen IP-Adressen, sondern als Kommunikation zwischen Objekten im Cluster, also zwischen Namespaces, Pods und Services. Routing- und Sicherheitsentscheidungen basieren damit nicht allein auf Quell- und Ziel-IP, sondern auf der Rolle eines Workloads innerhalb der Plattform. Dieses Modell passt besonders gut zu dynamischen Umgebungen, in denen sich IP-Adressen häufig ändern, während Dienste und ihre Beziehungen zueinander stabil bleiben.
Cilium setzt Network Policies nach Kubernetes-Standard ebenfalls über eBPF um und verzichtet dabei auf klassische Paketfilter. Regeln lassen sich dadurch sehr fein granular formulieren, ohne lange Regelketten zu pflegen. Auch bei umfangreichen Policy-Sets bleibt der Datenpfad performant. Gleichzeitig eröffnet dieser Ansatz Möglichkeiten, die über klassische Layer-3- und Layer-4-Filter hinausgehen. Das Plug-in unterstützt Layer-7-Policies, bei denen Entscheidungen anhand von HTTP-Methoden, Pfaden oder gRPC-Diensten getroffen werden. Netzwerk- und Anwendungsebene rücken dadurch deutlich näher zusammen.
Ein weiterer zentraler Aspekt von Cilium ist die enge Verzahnung von Netzwerk und Observability. Da eBPF den vollständigen Kontext jedes einzelnen Pakets kennt, kann Cilium detaillierte Telemetriedaten erfassen, ohne zusätzlichen Traffic zu erzeugen oder auf externe Datenquellen wie Logdateien angewiesen zu sein. Latenzen, Fehlerraten und Kommunikationsbeziehungen lassen sich direkt aus dem Kernel der beteiligten Compute-Knoten ableiten.
Diese Fähigkeiten machen Cilium nicht nur zu einem CNI-Plug-in, sondern zu einer Basis für weitergehende Plattformfunktionen wie Service Meshes ohne klassische Sidecar-Komponenten. Während Flannel oder Calico für eine feinere Steuerung des Datenverkehrs zusätzliche Helfer benötigen, verlagert Cilium diese Aufgaben vollständig in den Kernel.
Hohe Leistungsfähigkeit bei erhöhter Komplexität
Der funktionale Umfang von Cilium hat seinen Preis. Das Werkzeug setzt einen vergleichsweise aktuellen Linux-Kernel voraus, erfordert ein solides Verständnis von eBPF und bringt ein anderes Debugging-Modell mit sich als klassische Netzwerkinfrastrukturen. Fehler zeigen sich nicht mehr primär in fehlenden Routen oder fehlerhaften nftables-Regeln, sondern in unerwartetem Verhalten innerhalb eines stark optimierten Datenpfads. Für Administratoren bedeutet das eine steile Lernkurve und eine stärkere Abhängigkeit von den mitgelieferten Analyse- und Diagnosewerkzeugen.
Cilium eignet sich daher vor allem für Plattformen, die Netzwerk, Sicherheit und Observability bewusst zusammenführen wollen. Es skaliert in großen Clustern gut, erlaubt sehr feingranulare Steuerung und eröffnet technische Möglichkeiten, die mit klassischen SDN-Ansätzen kaum erreichbar sind. Gleichzeitig erfordert es klare Architekturentscheidungen und ein Team, das bereit ist, dieses Modell konsequent zu betreiben. Cilium steht damit weniger für eine schrittweise Weiterentwicklung bestehender CNI-Plug-ins als für einen grundlegenden Paradigmenwechsel. Netzwerk wird nicht mehr nur als Transportmechanismus verstanden, sondern als integraler Bestandteil der Plattformlogik.
Das passende SDN für die Umgebung identifizieren
Die Entscheidung zwischen Flannel, Calico und Cilium ist weniger eine Frage technischer Überlegenheit als eine bewusste Wahl des Betriebsmodells, des Sicherheitsanspruchs und der organisatorischen Reife. Alle drei Werkzeuge adressieren dasselbe Grundproblem, nämlich Pod-zu-Pod-Konnektivität in Kubernetes. Sie tun dies jedoch mit sehr unterschiedlichen Annahmen darüber, wie viel Kontrolle, Transparenz und Dynamik eine Plattform benötigt. An diesen Annahmen sollte sich die Auswahl orientieren.
Flannel passt besonders gut zu Umgebungen, in denen Kubernetes zunächst als funktionale Plattform eingesetzt wird und Netzwerk keine eigenständige Domäne mit hoher Komplexität darstellt. Typische Szenarien sind Entwicklungscluster, Test- und Staging-Umgebungen, kleinere Produktivsysteme oder Edge-Setups mit begrenzter Infrastruktur. Flannel überzeugt dort, wo der Fokus auf stabiler Grundkonnektivität liegt und der Administrator möglichst wenig Zeit in Netzwerkthemen investieren möchte. Das resultierende Netzwerkmodell bleibt überschaubar, vorhersehbar und wartungsarm.
An seine Grenzen stößt Flannel dort, wo erhöhte Sicherheitsanforderungen bestehen oder mehrere Teams denselben Cluster nutzen, ohne ihren Datenverkehr gegenseitig zu beeinflussen. Ohne native Network Policies entsteht ein vollständig offenes Netzwerk, das sich nur schwer kontrollieren lässt. Auch Umgebungen mit Compliancevorgaben, klaren Mandantengrenzen oder gezielter Trafficsteuerung zählen nicht zu den Stärken von Flannel. In solchen Szenarien eignet es sich höchstens als Einstieg oder Übergang, nicht jedoch als dauerhaft tragfähige Infrastruktur.
Calico schließt die funktionale Lücke zwischen reiner Konnektivität und tief integrierter Datenpfadlogik. Es eignet sich für Plattformen, die produktiv, mehrmandantenfähig und sicher betrieben werden sollen, ohne ein vollständig neues Netzwerkparadigma einzuführen. Besonders gut passt Calico zu klassischen Rechenzentrumsumgebungen, in denen Routing, IP-Adressierung und BGP bereits etabliert sind oder im Zuge der Einführung von eBGP genutzt werden sollen.
Der Administrator behält mit Calico ein klares Betriebsmodell mit eindeutig verteilten Verantwortlichkeiten. Pods fungieren als IP-Endpunkte, Policies steuern ihre Kommunikationsbeziehungen, und Pakete verschwinden nicht in Verkapselungstunneln. Das vereinfacht insbesondere die Fehlersuche, da sich Datenpfade mit bekannten Werkzeugen nachvollziehen lassen.
Obacht ist jedoch bei Calico dort geboten, wo sehr feingranulare Steuerung auf Anwendungsebene erforderlich ist oder wo Netzwerkverhalten eng mit Observability verzahnt werden soll. Für diese Anforderungen reagiert Calico bisweilen zu träge. Auch hochdynamische Szenarien mit ständig wechselnden Kommunikationsmustern fordern das Modell heraus. Calico bleibt ein leistungsfähiges, aber bewusst konservatives Werkzeug, das Stabilität und Berechenbarkeit höher gewichtet als maxi- male Flexibilität.
Cilium richtet sich an Plattformen, die Kubernetes als strategische Infrastruktur betreiben und Netzwerk, Sicherheit und Observability eng miteinander verzahnen wollen. Große Cluster, sicherheitskritische Umgebungen oder Organisationen mit einem starken Plattformteam profitieren besonders von diesem Ansatz. Cilium spielt seine Stärken dort aus, wo Identitäten wichtiger sind als IP-Adressen und wo Datenverkehr nicht nur transportiert, sondern auch dynamisch interpretiert und beeinflusst werden soll. Layer-7-Policies, tiefgehende Laufzeitbeobachtung und hohe Performance unter Last prädestinieren Cilium für anspruchsvolle Szenarien.
Cilium eignet sich hingegen nicht für Umgebungen, in denen Einfachheit oberste Priorität hat oder in denen Kernel- und eBPF-Know-how fehlen. In kleinen Clustern oder in Teams ohne tiefgehendes Linux-Verständnis erzeugt das Werkzeug schnell mehr Aufwand als Nutzen. Auch Administratoren mit einem stark konservativen Betriebsmodell, die Eingriffe in den Datenpfad möglichst vermeiden möchten, werden mit Cilium kaum warm.
OpenShift mit Sonderweg für SDN
OpenShift nimmt im Kubernetes-Ökosystem auch im Hinblick auf Software-defined Networking eine Sonderrolle ein. Während viele Kubernetes-Distributionen dem Administrator mehrere gleichberechtigte CNI-Plug-ins zur Auswahl stellen, trifft OpenShift in der Standardkonfiguration eine klare architektonische Vorentscheidung. Diese ist kein technischer Selbstzweck, sondern Ausdruck eines anderen Plattformverständnisses dieser Kubernetes-Umgebug.
Historisch setzte OpenShift zunächst auf ein eigenes SDN, das stark auf Open vSwitch und Overlay-Konzepte ausgerichtet war. Mit neueren Versionen hat Red Hat diesen Ansatz weiterentwickelt und standardmäßig auf OVN-Kubernetes umgestellt. OVN, das Open Virtual Network, baut auf Open vSwitch auf und ergänzt diesen um eine logisch zentrale Control Plane mit Northbound- und Southbound-Datenbanken. Netzwerkzustände, Policies und Topologien werden dort zentral modelliert und anschließend auf die einzelnen Nodes verteilt.
Technologisch kombiniert OpenShift mehrere SDN-Komponenten. Open vSwitch übernimmt die Paketverarbeitung auf den Nodes, OVN steuert Routing, Overlay-Netze und Network Policies, und Kubernetes liefert die deklarativen Objekte, aus denen sich diese Steuerlogik ableitet. Entscheidend ist jedoch weniger die Auswahl der Einzeltechnologien als deren enge Verzahnung. OpenShift behandelt Netzwerk nicht als austauschbares Plug-in, sondern als festen Bestandteil der Plattformarchitektur.
Für den Administrator bedeutet dieser Ansatz eine deutliche Einschränkung der Wahlmöglichkeiten. OpenShift nimmt ihm zentrale Architekturentscheidungen ab, verlangt dafür aber die Akzeptanz des vorgegebenen SDN-Modells. OVN-Kubernetes bietet leistungsfähige Network Policies, eine saubere Integration von "Ingress" und "Egress" sowie eine konsistente Sicht auf den gesamten Cluster. Gleichzeitig steigt die Komplexität im Betrieb. Das Debugging verlagert sich stärker in die zentrale Control Plane. Netzwerkprobleme lassen sich seltener durch die Analyse einzelner Nodes lösen, sondern erfordern ein Verständnis von OVN-Flows, Datenbanken und Controller-Logik. Diese Komponenten greifen eng ineinander und sind für sich genommen bereits komplex. SDN im Open-Shift-Umfeld erweist sich damit nicht als Selbstläufer, sondern als bewusst gewählter Trade-off zwischen Flexibilität und Betriebsstabilität.
Fazit
Flannel, Calico und Cilium adressieren dasselbe Grundproblem, setzen dabei jedoch auf sehr unterschiedlichen Ebenen an. Der Vergleich macht deutlich, dass es bei der Auswahl eines CNI-Plug-ins nicht um einzelne Funktionen geht, sondern um die grundsätzliche Frage, wie Netzwerk in Kubernetes verstanden und betrieben werden soll. Jedes der drei Werkzeuge steht für ein eigenes Verständnis von Komplexität, Kontrolle und Verantwortung.
Software-defined Networking erweist sich in diesem Zusammenhang nicht als austauschbares Detail, sondern als zentrale Architekturentscheidung. Mit der Wahl des SDN-Ansatzes legt ein IT-Verantwortlicher fest, wie gut sich eine Kubernetes-Plattform skalieren, absichern und im Betrieb nachvollziehen lässt. Eine bewusste Entscheidung entlang der eigenen Anforderungen schützt besser vor späteren Reibungsverlusten als der Griff zu einem vermeintlich "modernsten" Werkzeug.
(jp)
Links
[1] Flannel: https://it-a.eu/q3p41
[2] Calico: https://it-a.eu/q3p42
[3] Cilium: https://it-a.eu/q3p43