Skalierbare Plattformen wie Kubernetes verändern nicht nur, wie Anwendungen laufen, sondern auch, wie sich deren Netzwerkverkehr verhält und wie er sich steuern lässt. In klassischen Umgebungen plant der Administrator Netze im Voraus. Er definiert VLANs, legt Subnetze fest, verteilt IP-Adressen und verbindet Server über fest konfigurierte Switchports. Die Welt bleibt dabei vergleichsweise statisch: Ein Dienst läuft auf einem bestimmten Host oder in einem klar umrissenen Cluster. Änderungen erfolgen geplant und kontrolliert.

Kubernetes organisiert seine Workloads dagegen deutlich dynamischer. Dessen Scheduler verteilt Pods über viele Knoten, verschiebt sie bei Bedarf und ersetzt sie automatisch bei Ausfällen. Damit wandert nicht nur Rechenlast zwischen Systemen, sondern auch deren Netzwerkkommunikation. Ein Dienst, der heute auf Knoten 1 läuft, antwortet morgen möglicherweise von Knoten 5, ohne dass der Administrator aktiv eingreift. Diese Arbeitsweise erzwingt ein hohes Maß an Flexibilität: Soll die Plattform nahtlos horizontal skalieren, muss prinzipiell jeder Workload auf jedem Zielsystem lauffähig sein und mit Diensten und Applikationen desselben Mandanten auf anderen Knoten kommunizieren können. Klassische Ansätze wie VLANs stoßen hier schnell an Grenzen. Sie beruhen auf der Annahme, dass Netzzuordnung und Workload-Platzierung langfristig zusammenpassen – eine Annahme, die Kubernetes nicht teilt.

SDN entkoppelt Netzlogik von physischer Infrastruktur

VLANs adressieren ein Problem, das fast so alt ist wie die IT selbst: die Trennung von Layer-2-Domänen und die Segmentierung von Netzen. In kleinen und mittleren Umgebungen funktioniert dieses Modell gut, solange die Anzahl der Segmente überschaubar bleibt und Änderungen selten auftreten. In Plattformen wie Kubernetes, die auf Selbstbedienung, Mandantenfähigkeit und schnelle Bereitstellung ausgelegt sind, entwickelt sich VLAN jedoch zum administrativen Nadelöhr.

Sobald Teams neue Setups anlegen, zusätzliche Namespaces entstehen oder Services mit eigenen Sicherheitsanforderungen starten, müsste der Administrator im VLAN-Modell fortlaufend neue VLANs definieren, Switch-Konfigurationen anpassen, Trunks erweitern und Firewallregeln auf mehreren Ebenen nachziehen. In einem Kubernetes-Cluster gehören solche Änderungen jedoch zum Normalzustand. Wer eine Plattform mit Dutzenden oder Hunderten Knoten betreibt, kann diesen Aufwand nicht dauerhaft manuell bewältigen, ohne dass das Netzwerk zum Bremsklotz für die gesamte Umgebung wird.

Software-defined Networking (SDN) setzt genau an dieser Stelle an. SDN behandelt Netzwerke nicht länger als starre physische Struktur, sondern als programmierbare Ressource, die sich dynamisch an die Anforderungen der Plattform anpasst. Der Kern des SDN-Ansatzes liegt darin, dass eine zentrale oder logisch zentrale Steuerinstanz vorgibt, wie Pakete fließen sollen, und dass die beteiligten Datenpfade diese Vorgaben umsetzen.

In der Praxis bedeutet das: Statt VLANs als physische Segmente zu planen, erzeugt die Plattform logische Netze, die unabhängig von der zugrunde liegenden Topologie funktionieren. Workloads kommunizieren über ein virtuelles Netzwerk, das sich über viele Knoten spannen lässt, ohne dass jeder Switch im Underlay jedes Detail kennen muss. Kubernetes benötigt diese Entkopplung, weil es Netzwerke nicht als statische Infrastruktur begreift, sondern als integralen Bestandteil des Orchestrierungsmodells.

Mit SDN verändert sich zwangsläufig auch die Rolle klassischer Netzwerkhardware. In traditionellen Netzen übernimmt der Switch nicht nur das Weiterleiten des Datenverkehrs, sondern bringt als Teil seiner eigenen Control Plane erhebliche Intelligenz mit. Er pflegt MAC-Tabellen, nutzt Routingprotokolle wie BGP oder OSPF, erzwingt ACLs und bietet zahlreiche Stellschrauben für eine komplexe Konfiguration.

Im SDN-Modell reduziert sich der Switch auf seine Kernaufgabe: Pakete effizient weiterzuleiten. Die Steuerlogik wandert in Software, die als Teil der Orchestrierungsplattform eine globale Sicht auf alle relevanten Netzbeziehungen besitzt und Konfigurationen zentral vorgibt. Für den Admin eröffnet das neue Möglichkeiten: Regeln orientieren sich nicht mehr an Portnummern oder Trunk-Listen, sondern an Plattformobjekten, die Kubernetes ohnehin kennt – etwa Namespaces, Services oder Labels.

SDN materialisiert sich über mehrere technische Bausteine

Software-defined Networking muss sich in skalierbaren Plattformen auf den konkret beteiligten Systemen umsetzen lassen. Ein vom Admin angestoßenes Deployment einer Anwendung, die aus mehreren Komponenten besteht und sich über viele Knoten verteilt, muss am Ende ein funktionierendes physisches wie logisches Netzwerk zwischen all diesen Bausteinen erzeugen.

Am Markt existieren dafür unterschiedliche Ansätze. Sie unterscheiden sich im Detail, folgen aber demselben Grundprinzip: Die Steuerlogik liegt in Software, die Datenpfade setzen diese Vorgaben um, und die Plattform – hier Kubernetes – definiert die nötige Konfiguration verbindlich. In der Praxis haben sich mehrere Modelle etabliert, die jeweils andere Schwerpunkte setzen – wir betrachten im Folgenden die Beispiele Open vSwitch, eBPF und BGP.

Open vSwitch als klassisches SDN

Open Virtual Networking (OVN) in Kombination mit Open vSwitch (OVS) steht für ein klassisches SDN-Modell. Der Ansatz implementiert auf jedem Host einen virtuellen Switch auf Basis des OpenFlow-Standards, der den Datenverkehr zwischen Containern, Pods und physischen Netzwerken steuert. Für die Anbindung über mehrere Knoten hinweg kommen Tunnelmechanismen wie VXLAN oder Geneve zum Einsatz. Die Steuerregeln definiert eine zentrale Instanz und verteilt sie als Flow-Tabellen an die virtuellen Switches auf allen beteiligten Systemen.

Dieses Modell erinnert stark an traditionelle Rechenzentrumsnetze, verlagert die Control Plane physischer Switches jedoch in Software auf die einzelnen Server. Es eignet sich vor allem für Umgebungen mit komplexen Netzwerktopologien, vielen Mandanten und hohem Bedarf an feingranularer Steuerung. In OpenShift begegnet dem Admin dieser Ansatz standardmäßig.

eBPF verzichtet auf virtuelle Switches

Einen grundlegend anderen Ansatz verfolgt eBPF: Statt einen expliziten virtuellen Switch einzusetzen, platziert eBPF kleine Programme direkt im Linux-Kernel. Diese Programme analysieren Netzwerkpakete und können sie verändern oder filtern, noch bevor sie klassische Netzwerkpfade durchlaufen. Der Vorteil liegt in geringer Latenz und hoher Flexibilität, da sich das Verhalten dynamisch anpassen lässt, ohne Switches – physisch oder virtuell – betreiben zu müssen.

In Kubernetes-Umgebungen gewinnt dieser Ansatz zunehmend an Bedeutung, weil er Netzwerk, Sicherheit und Observability auf einer gemeinsamen technischen Basis vereint. Aus eBPF heraus lassen sich nicht nur Netzwerkentscheidungen treffen, sondern auch detaillierte Informationen über den Zustand von Workloads und Knoten gewinnen.

BGP bindet Netze direkt ins Underlay ein

Das Border Gateway Protocol (BGP) wirkt auf den ersten Blick weniger wie SDN, spielt aber in mehreren Kubernetes-Netzwerkmodellen eine zentrale Rolle. Häufig übernimmt BGP die Aufgabe, Pod-Netze oder Service-IP-Bereiche innerhalb der Plattform und gegenüber dem physischen Netzwerk bekannt zu machen. Die Steuerlogik liegt dabei weiterhin in Software, etwa in Quagga, FRR oder Bird, während das Underlay primär Routinginformationen austauscht.

Dieser Ansatz verzichtet meist auf Overlays und bindet Kubernetes-Netze direkt in die bestehende Infrastruktur ein. Er eignet sich besonders für Umgebungen, die Kubernetes eng mit vorhandenen Netzwerkstrukturen verzahnen wollen. SDN in Kubernetes ist damit nicht an eine einzelne Technologie gebunden. Entscheidend ist nicht, ob Open vSwitch, eBPF oder BGP zum Einsatz kommt, sondern dass sich das Netzwerkverhalten der Plattform programmatisch steuern und dynamisch aus Kubernetes heraus anpassen lässt.

Kubernetes trennt Netzwerklogik und Plattform

Unabhängig vom technischen Ansatz bringt Kubernetes ein grundsätzliches Umsetzungsproblem mit. Zwar beschreibt die Plattform explizit wie implizit, wie Pods miteinander kommunizieren sollen, sie bringt jedoch keine eigene Funktionalität mit, um diese Vorgaben direkt im Betriebssystem oder im Netzwerk umzusetzen. Das ist kein Mangel, sondern eine bewusste Designentscheidung.

Zwar ließen sich entsprechende Funktionen theoretisch im Kubelet verankern, die Kubernetes-Entwickler setzen jedoch konsequent auf eine klare Aufgabentrennung. Kubernetes weiß, dass ein Pod existiert, welche IP-Adresse er besitzt und zu welchem Service er gehört. Das System verfügt jedoch nicht über die Information, wie das Netzwerk auf jedem Node im Detail konfiguriert werden muss, damit Pakete den korrekten Pfad beschreiten.

Ohne eine standardisierte Schnittstelle müsste jede Kubernetes-Distribution eigene Mechanismen zur Netzwerkkonfiguration entwickeln. Das würde Fragmentierung fördern und die Netzwerklogik fest mit dem Plattformkern verknüpfen. Kubernetes vermeidet diesen Weg bewusst und delegiert die Umsetzung an spezialisierte externe Komponenten.

An dieser Stelle kommt das Container Networking Interface (CNI) ins Spiel. CNI ist keine eigene SDN-Implementierung, sondern eine klar definierte Schnittstelle, über die Kubernetes Netzwerkfunktionen an Plug-ins auslagert. Diese Plug-ins übernehmen Aufgaben wie das Anbinden von Pods an das Netzwerk, die Vergabe von IP-Adressen sowie die Konfiguration von Routing oder Forwarding. Kubernetes selbst ruft sie lediglich zu definierten Zeitpunkten auf, etwa beim Erstellen oder Löschen eines Pods.

Dabei übergibt Kubernetes dem jeweiligen Plug-in Informationen über Pod, Namespace und gewünschte Netzwerkumgebung. Das Plug-in setzt diese Vorgaben lokal auf dem Compute-Knoten um, indem es virtuelle Interfaces anlegt, Routen setzt, Filterregeln installiert oder Flow-Tabellen aktualisiert. Die konkrete Umsetzung hängt vollständig vom jeweiligen Plug-in ab.

CNI-Plug-ins abstrahieren SDN

Kubernetes implementiert SDN somit nie direkt, sondern immer über CNI-Plug-ins. Werkzeuge wie Flannel, Calico oder Cilium stehen exemplarisch für unterschiedliche technische Ansätze, nicht für verschiedene Funktionsstufen. Flannel stellt vor allem grundlegende Konnektivität bereit, Calico ergänzt Routing und Policys, Cilium verlagert große Teile der Logik in den Linux-Kernel. Wie Sie diese Werkzeuge konkret einsetzen, zeigt der nachfolgende Beitrag.

Für das Verständnis von Kubernetes-SDN ist jedoch weniger entscheidend, welches Plug-in zum Einsatz kommt. Alle genannten Werkzeuge implementieren zunächst das virtuelle Gegenstück zum physischen Layer 2 und stellen die logische Verbindung zwischen Containern auf unterschiedlichen Systemen her. Mindestens ebenso relevant ist, welche zusätzlichen Netzwerkabstraktionen Kubernetes darauf aufsetzt und wie sich diese in die jeweilige SDN-Implementierung integrieren.

Ingress in SDN abbilden

Ein wichtiges Beispiel ist eingehender Traffic, im Kubernetes-Kontext als Ingress bezeichnet. Aus SDN-Sicht stellt Ingress keinen normalen Netzwerkverkehr zwischen Pods dar, sondern eine abstrahierte Eintrittsstelle in den Cluster. Kubernetes beschreibt über Ingress-Ressourcen lediglich, welche Dienste von außen erreichbar sein sollen und unter welchen Bedingungen. Die konkrete Umsetzung – etwa Loadbalancing, TLS-Terminierung und Routing – übernimmt ein Ingress-Controller, der seinerseits tief in das SDN der Plattform eingebettet ist.

Der entscheidende Punkt: Ingress operiert oberhalb des eigentlichen Pod-Netzwerks. Eingehender Verkehr trifft zunächst auf einen dedizierten Eintrittspunkt, der nicht mit klassischer Pod-zu-Pod-Kommunikation identisch ist. SDN muss diesen Traffic daher explizit abbilden, etwa über zusätzliche virtuelle Schnittstellen, spezielle Routingregeln oder dedizierte Proxys. Damit wird deutlich, dass Kubernetes-SDN nicht nur interne Kommunikation steuert, sondern auch die Übergänge zwischen externen und internen Netzen kontrolliert.

Mit dem Gateway-API entwickelt Kubernetes dieses Modell konsequent weiter. Während Ingress lange als monolithische Abstraktion fungierte, trennt das Gateway-API klar zwischen Infrastruktur und Nutzung. Gateways repräsentieren verfügbare Netzwerkfähigkeiten, Routen definieren deren konkrete Verwendung. Diese Trennung passt sowohl zum SDN- als auch zum Kubernetes-Gedanken. Die Plattform beschreibt deklarativ, welche Netzwerkfunktionen bereitstehen, und überlässt deren Umsetzung einer darunterliegenden Steuerlogik. SDN-Komponenten erhalten dadurch klar definierte Schnittstellen und weniger implizite Annahmen, was langfristig stabilere und besser integrierbare Netzarchitekturen ermöglicht.

Anwendungen mit Service Meshes steuern

Eine weitere Besonderheit bringen Service Meshes ins Spiel. Mesh-Umgebungen wie Istio oder Linkerd arbeiten nicht auf klassischer Netzwerkebene, sondern auf Ebene der Anwendungsprotokolle. Dennoch greifen sie tief in das Netzwerkverhalten ein. Sidecar-Proxys übernehmen Trafficsteuerung, Verschlüsselung und Observability, während das zugrunde liegende SDN weiterhin die logische Verbindung zwischen den Pods sicherstellt.

De facto entsteht damit eine zweistufige Netzwerksteuerung. Das SDN stellt sicher, dass Pods miteinander kommunizieren können und das Mesh kontrolliert, wie diese Kommunikation abläuft. Kubernetes verbindet beide Ebenen, indem es Traffic gezielt über definierte Pfade lenkt. Für die Plattform bedeutet das, dass Netzwerke nicht mehr ausschließlich paketorientiert arbeiten, sondern zunehmend identitäts- und richtlinienbasiert. Service Meshes sind dabei keineswegs Pflicht. Viele Kubernetes-Umgebungen kommen problemlos ohne sie aus. Wer jedoch zusätzliche Steuerungs- und Sicherheitsfunktionen benötigt, findet hier ein mächtiges Werkzeug.

Network Policys in SDN

Besonders wichtig ist die Rolle von SDN bei Network Policys. Kubernetes beschreibt Sicherheit nicht in Form klassischer Firewallregeln, sondern über deklarative Beziehungen zwischen Workloads. SDN-Implementierungen übersetzen diese Vorgaben in konkrete Filter- oder Forwarding-Regeln auf den beteiligten Systemen. Policys sind dabei kein optionales Beiwerk, sondern ein zentrales Steuerinstrument. Wer Workloads unterschiedlicher Mandanten innerhalb eines Kubernetes-Clusters betreibt, muss Network Policys einsetzen, um deren Traffic zuverlässig voneinander zu trennen.

Fazit

Software-defined Networking ist im Kubernetes-Umfeld kein technisches Detail, sondern in den meisten Szenarien eine zwingende Voraussetzung. Die Dynamik der Plattform, die Kurzlebigkeit von Workloads und die konsequente Abstraktion der Infrastruktur lassen sich mit klassischen, VLAN-basierten Modellen nur mit erheblichem Aufwand abbilden. Kubernetes verlangt ein deutlich flexibleres Netzwerk.

SDN liefert dafür den konzeptionellen und praktischen Rahmen. Durch die Trennung von Steuerlogik und Datenpfad wird Netzwerk programmierbar und eng an die Konfiguration der Plattform gekoppelt. CNI fungiert dabei als Integrationsschicht, über die sich unterschiedliche SDN-Ansätze einbinden lassen, ohne den Kubernetes-Kern anzutasten. Konzepte wie Ingress, Gateway-API, Network Policys oder Service Meshes bauen genau auf dieser Abstraktion auf. (jp)