Wer Architekturentscheidungen rund um AKS-Netzwerke treffen will, kommt an den Unterschieden zwischen Azure CNI, CNI Overlay und Kubenet nicht vorbei. Die gewählte Netzwerkoption bestimmt, wie Pods kommunizieren, wie IP-Adressen vergeben werden und welche Funktionen Ihrem Cluster zur Verfügung stehen. Alle Lösungen sorgen für Pod-Konnektivität, unterscheiden sich aber in Implementierung, Performance und Skalierbarkeit. Dieser technische Überblick beleuchtet die wesentlichen Unterschiede zwischen Azure CNI (im klassischen Modus wie im Overlay-Modus) und Kubenet – mit Fokus auf IP-Adressverwaltung, Netzwerk-Performance und Integrationsmöglichkeiten – und liefert die Grundlage für Ihre AKS-Netzwerkstrategie.
IP-Adressverwaltung
Beim klassischen Azure CNI bekommt jeder Pod seine IP-Adresse direkt aus dem Subnetz Ihres Azure Virtual Network. Pods werden damit zu vollwertigen Netzwerkteilnehmern innerhalb Ihres VNet und kommunizieren direkt mit anderen Ressourcen in Ihrer Azure-Umgebung. Die Pod-IPs sind routbar und für jede Ressource erreichbar, die Netzwerkzugriff auf das Subnetz hat.
Azure CNI bietet inzwischen auch einen Overlay-Modus, bei dem nur die Cluster-Knoten in einem Subnetz bereitgestellt werden. Pods erhalten IP-Adressen aus einem privaten CIDR-Bereich, der logisch vom VNet der Knoten getrennt ist. Pod- und Knoten-Traffic innerhalb des Clusters läuft über ein Overlay-Netzwerk, während Network Address Translation (NAT) die Knoten-IP nutzt, um Ressourcen außerhalb des Clusters zu erreichen. Das spart erhebliche Mengen an IP-Adressen und erlaubt eine deutlich größere Cluster-Skalierung.
Auch Kubenet setzt auf ein Overlay-Netzwerk. Pods erhalten IP-Adressen aus einem separaten Adressraum, der nicht Teil Ihres VNet ist. Müssen Pods mit Ressourcen außerhalb des Clusters kommunizieren, leitet Kubenet den Datenverkehr per NAT über die IP-Adresse des Knotens. Das erzeugt zwar einen zusätzlichen Netzwerk-Hop, schont aber VNet-IP-Adressen, da nur die Knoten IPs aus Ihrem Subnetz benötigen.
Anforderungen an den Subnetz-Adressraum
Beim klassischen Azure CNI muss die Subnetz-Planung sorgfältig erfolgen, denn jeder potenzielle Pod benötigt eine eigene IP-Adresse aus Ihrem Subnetz. Sie müssen also ein Subnetz wählen, das groß genug ist, um alle Knoten und deren maximal mögliche Pod-Anzahl aufzunehmen. Wenn jeder Knoten 30 Pods ausführen kann und Sie auf 10 Knoten skalieren wollen, brauchen Sie mindestens 300 IP-Adressen für Pods – plus zusätzliche IPs für die Knoten selbst. Diese Anforderung zwingt häufig zu größeren CIDR-Bereichen und prägt das gesamte Netzwerkdesign.
Azure CNI Overlay nutzt IP-Adressen effizienter und weist jedem Knoten einen /24-Adressraum aus einem bei der Cluster-Erstellung definierten privaten CIDR zu. Der /24-Block ist fest und unterstützt bis zu 250 Pods pro Knoten. Sie können denselben Pod-CIDR-Bereich über mehrere unabhängige AKS-Cluster im selben VNet hinweg wiederverwenden und damit den verfügbaren IP-Raum für containerisierte Anwendungen erheblich vergrößern.
Auch Kubenet geht sparsam mit IP-Adressen um, da nur die Knoten selbst VNet-IPs benötigen. Pods nutzen einen internen CIDR-Bereich für das Overlay-Netzwerk, standardmäßig meist 10.244.0.0/16, der den Adressraum Ihres VNet nicht belastet. Damit ist Kubenet eine gute Wahl in Umgebungen mit knappen IP-Adressen oder strengen Vorgaben. Diese Effizienz erkauft man sich allerdings mit zusätzlichem Routing-Aufwand über User Defined Routes (UDRs).
Netzwerk-Performance
Das klassische Azure CNI liefert dank seiner direkten Netzwerk-Integration die beste Performance. Da Pods ohne Overlay-Netzwerk direkt am VNet hängen, entsteht kaum Overhead im Netzwerk-Stack. Pakete fließen ohne zusätzliche Kapselung oder Übersetzung direkt zwischen Pods und anderen VNet-Ressourcen – das bedeutet niedrigere Latenz und höheren Durchsatz für netzwerkintensive Workloads.
Azure CNI Overlay erreicht eine Performance, die mit VMs in einem VNet vergleichbar ist. Es müssen weder benutzerdefinierte Routen bereitgestellt noch Kapselungsverfahren zum Tunneln des Pod-Traffics genutzt werden, sodass die Konnektivität zwischen Pods auf dem Niveau von VNet-VMs liegt.
Kubenet bringt zusätzlichen Netzwerk-Overhead mit sich, da NAT und Routing über die Netzwerkschnittstelle des Knotens nötig sind. Jedes Paket muss vom Overlay-Netzwerk verarbeitet und zwischen der internen Pod-IP und der externen Knoten-IP übersetzt werden. Für viele Anwendungen fällt das kaum ins Gewicht, kann aber bei hohem Netzwerkdurchsatz oder latenzkritischen Workloads spürbar werden.
Steuerung über Network Security Groups (NSGs)
Azure CNI arbeitet mit NSGs auf Subnetz- und Netzwerkschnittstellenebene; Regeln können Pod-IPs adressieren, da diese Teil des VNet sind. NSGs lassen sich zwar nicht direkt an einzelne Pods anhängen, Sie können aber NSG-Regeln definieren, die einzelne Pods oder Pod-Gruppen über ihre VNet-IPs gezielt ansprechen.
Bei Azure CNI Overlay wird Pod-zu-Pod-Traffic nicht gekapselt, und Subnetz-NSG-Regeln greifen weiterhin. Für die korrekte Cluster-Funktion sind bestimmte Regeln nötig, etwa für den Verkehr zwischen Knoten- und Pod-CIDR-Bereichen. Zur Steuerung des Workload-Traffics empfiehlt sich der Einsatz von Network Policies.
Bei Kubenet beschränkt sich die Netzwerksicherheit auf die Knotenebene, da Pods keine direkten VNet-IPs besitzen. NSG-Regeln lassen sich nur auf die Netzwerkschnittstelle des Knotens anwenden – alle Pods auf einem Knoten teilen sich also dieselben Sicherheitsregeln. Das erschwert pod-spezifische Netzwerkrichtlinien und macht oft alternative Lösungen wie Kubernetes Network Policies erforderlich, um den Datenverkehr innerhalb des Clusters feiner zu steuern.
VNet-Integration
Das klassische Azure CNI bietet eine umfassende VNet-Integration: Pods kommunizieren direkt mit jeder Ressource Ihrer Azure-Umgebung, die mit dem VNet verbunden ist – darunter Azure-Dienste wie SQL Managed Instances, Azure Cache for Redis oder Ressourcen in gepeerten VNets. Da Pods ihre IP-Adressen direkt aus dem VNet-Subnetz beziehen, lassen sich Verbindungen ohne zusätzliche Netzwerkkonfiguration aufbauen – ideal für Szenarien, die eine nahtlose Anbindung an andere Azure-Dienste verlangen.
Azure CNI Overlay realisiert die VNet-Integration über NAT, wobei ausgehender Pod-Traffic die IP-Adresse des Knotens nutzt. Pods sind zwar nicht direkt von außerhalb des Clusters erreichbar, Sie können Pod-Anwendungen aber als Kubernetes-Load-Balancer-Services veröffentlichen, um sie im VNet verfügbar zu machen.
Kubenet bietet eine deutlich eingeschränktere VNet-Integration. Pods können zwar weiterhin mit externen Ressourcen kommunizieren, dafür sind jedoch UDRs erforderlich, um den Datenverkehr korrekt zwischen Pod-Overlay-Netzwerk und VNet zu routen. Diese zusätzliche Routing-Komplexität kann die Konnektivität zu bestimmten Azure-Diensten beeinträchtigen und erfordert oft zusätzlichen Konfigurationsaufwand bei VNet-Peering- oder Hybrid-Netzwerk-Szenarien. Mit wachsender Netzwerkarchitektur wird das Routing entsprechend komplexer.
Routing-Tabellen-Verwaltung und Setup-Komplexität
Bei der Verwaltung von Routing-Tabellen unterscheiden sich die Optionen deutlich. Das klassische Azure CNI vereinfacht das Routing-Management, weil Pods direkt im VNet kommunizieren und keine zusätzlichen Einträge in der Routing-Tabelle für den Pod-Traffic nötig sind. Die Konfiguration bleibt auch bei wachsendem Cluster überschaubar. Der Aufwand verlagert sich jedoch in die initiale Planung, in der eine sorgfältige IP-Adressplanung gefragt ist.
Azure CNI Overlay vereinfacht das Pod-Networking, weil – anders als bei Kubenet – keine UDRs für die grundlegende Konnektivität erforderlich sind. Zwar müssen für den ordnungsgemäßen Cluster-Betrieb bestimmte NSG-Regeln konfiguriert werden, doch die Lösung übernimmt das Pod-zu-Pod-Routing automatisch und erreicht eine Performance auf dem Niveau klassischer VNet-Kommunikation. UDRs können in Spezialfällen wie Forced Tunneling oder bei individuellen Routing-Anforderungen weiterhin sinnvoll sein.
Kubenet nutzt UDRs und IP-Forwarding für die Pod-Konnektivität, die der AKS-Dienst standardmäßig automatisch erstellt und pflegt. Optional können Sie eine eigene Routing-Tabelle einbringen, im Standardfall ist jedoch keine manuelle Pflege nötig. Die wesentliche Einschränkung: Azure unterstützt maximal 400 Routen pro UDR, was Ihren Cluster effektiv auf 400 Knoten begrenzt. Das Initial-Setup ist einfacher als beim klassischen Azure CNI, weil keine umfangreiche IP-Adressplanung nötig ist – Sie müssen lediglich die Knoten-IPs in Ihrem Subnetz einplanen. Die UDR-Architektur fügt allerdings einen zusätzlichen Netzwerk-Hop hinzu, der die Pod-Kommunikation leicht verzögert. Außerdem lassen sich Subnetze nicht zwischen mehreren Kubenet-Clustern teilen.
Zusätzliche Funktionen
Jede Netzwerkoption unterstützt unterschiedliche erweiterte Funktionen. Das klassische Azure CNI bietet die breiteste Funktionsabdeckung, einschließlich Windows-Containern, Azure Network Policies und Application Gateway-Integration. Azure CNI Overlay unterstützt Windows-Container und verschiedene Network-Policy-Optionen (Azure, Calico, Cilium), kann aber kein Application Gateway als Ingress Controller nutzen. Beide CNI-Modi unterstützen Dual-Stack-Networking, wobei Overlay einige Einschränkungen hat. Kubenet ist deutlich limitierter: Es funktioniert nur mit Linux-Containern und Calico-Network-Policies, unterstützt maximal 400 Knoten mit 250 Pods pro Knoten und ist bei Network Policies auf Calico beschränkt. Windows-Container und fortgeschrittene Azure-Netzwerkfunktionen werden nicht unterstützt.
Welche Option ist die richtige?
Die Wahl der Netzwerkoption hängt von Ihren konkreten Workload-Anforderungen und Infrastruktur-Restriktionen ab:
Das klassische Azure CNI eignet sich am besten für Enterprise-Workloads mit Anforderungen an direkte Netzwerkintegration, hohe Performance oder fortgeschrittene Azure-Service-Integration. Wählen Sie diese Option, wenn:
- genügend IP-Adressraum verfügbar ist
- der Großteil der Pod-Kommunikation mit Ressourcen außerhalb des Clusters erfolgt
- Ressourcen außerhalb des Clusters Pods direkt erreichen müssen
- Sie erweiterte AKS-Funktionen wie Virtual Nodes benötigen
- eine Application Gateway-Integration erforderlich ist
Azure CNI Overlay ist ideal für große Deployments mit knappem IP-Adressraum. Wählen Sie diese Option, wenn:
- Sie auf eine große Anzahl von Pods skalieren müssen, aber nur begrenzten IP-Adressraum haben
- der Großteil der Pod-Kommunikation innerhalb des Clusters stattfindet
- Sie eine einfachere Netzwerkkonfiguration wünschen
- Sie Windows-Container-Unterstützung brauchen, aber keinen Application Gateway Ingress Controller
- Sie Pod-CIDR-Bereiche über Cluster hinweg wiederverwenden möchten
Kubenet eignet sich gut für einfache Linux-Workloads und Umgebungen mit IP-Adress-Restriktionen. Wählen Sie diese Option, wenn:
- Sie einfache, ausschließlich Linux-basierte Workloads betreiben
- Sie IP-Adress-Restriktionen haben, aber die Skalierung von CNI Overlay nicht benötigen
- Sie keine erweiterten Netzwerkfunktionen benötigen
- Sie Entwicklungs- oder Testumgebungen aufsetzen
Die Wahl des Netzwerk-Plugins für Ihren AKS-Cluster hat langfristige Auswirkungen auf Skalierbarkeit, Performance und operativen Aufwand. Die jeweiligen Eigenschaften und Grenzen zu kennen, ist entscheidend für eine fundierte Entscheidung, die zu Ihren Infrastrukturanforderungen und Wachstumsplänen passt. Bedenken Sie: Ein Wechsel der Netzwerkoption setzt in der Regel ein Neuaufsetzen des Clusters voraus – diese Entscheidung sollte daher früh in Ihrer AKS-Planung fallen.
Ein wichtiger Hinweis zum Schluss: Am 31. März 2028 wird Kubenet-Networking für AKS abgekündigt. Azure CNI Overlay bietet sich als geeigneter Nachfolger an, der viele Limitierungen von Kubenet adressiert und gleichzeitig eine effiziente IP-Adressnutzung ermöglicht.
Sprechen Sie noch heute mit DoiT darüber, wie wir Ihre Cloud-Umgebung effizienter, wirtschaftlicher und sicherer machen. Mit DoiT erhalten Sie Zugang zu ausschließlich Senior-Cloud-Expertise für Beratung, Weiterbildung und Support – immer dann, wenn Sie fundierten Rat, eine zweite Meinung, Unterstützung bei der Einführung neuer Technologien oder Hilfe beim Löschen produktionskritischer Brände brauchen.
Wenn Sie tiefer in weitere Themen rund um Cloud-Sicherheit und -Architektur einsteigen möchten, werfen Sie einen Blick in unsere Cloud-Engineering-Blogbeiträge.