Azure Container Networking Interface Overlay-Netztechnologie (CNI)

Mithilfe von Azure CNI Overlay werden die Clusterknoten in einem Azure Virtual Network-Subnetz (VNet) bereitgestellt. Pods werden IP-Adressen aus einem privaten CIDR zugewiesen, das sich logisch vom VNet-Hosting der Knoten unterscheidet. Pod- und Knotendatenverkehr innerhalb des Clusters verwendet ein Überlagerungsnetzwerk. Die Netzwerkadressübersetzung (Network Address Translation, NAT) verwendet die IP-Adresse des Knotens, um Ressourcen außerhalb des Clusters zu erreichen. Mit dieser Lösung wird eine erhebliche Menge an VNet-IP-Adressen eingespart, und Sie können Ihren Cluster auf große Größen skalieren. Ein zusätzlicher Vorteil besteht darin, dass das private CIDR in verschiedenen AKS-Clustern wiederverwendet werden kann, wodurch der für containerisierte Anwendungen in Azure Kubernetes Service (AKS) verfügbare IP-Adressraum erweitert wird.

Übersicht über das Überlagerungsnetzwerk

Im Überlagerungsnetzwerk werden nur den Kubernetes-Clusterknoten IPs aus Subnetzen zugewiesen. Pods erhalten IPs von einem privaten CIDR, das zum Zeitpunkt der Clustererstellung bereitgestellt wird. Jedem Knoten wird ein /24-Adressraum zugewiesen, der aus demselben CIDR stammt. Zusätzliche Knoten, die beim Aufskalieren eines Clusters erstellt werden, erhalten automatisch „/24“-Adressräume aus demselben CIDR. Azure CNI weist Pods IPs aus diesem /24-Raum zu.

Eine separate Routingdomäne wird im Azure-Netzwerkstapel für den privaten CIDR-Raum des Pods erstellt, der ein Überlagerungsnetzwerk für die direkte Kommunikation zwischen Pods erstellt. Es ist nicht erforderlich, benutzerdefinierte Routen im Clustersubnetz bereitzustellen oder eine Kapselungsmethode zum Tunneln des Datenverkehrs zwischen Pods zu verwenden, was eine Konnektivitätsleistung zwischen Pods auf dem Niveau von VMs in einem VNet ermöglicht. Workloads, die innerhalb der Pods ausgeführt werden, wissen nicht einmal, dass die Netzwerkadressen bearbeitet werden.

Die Kommunikation mit Endpunkten außerhalb des Clusters, wie z. B. mit lokalen VNets und VNets mit Peering, erfolgt mithilfe der Knoten-IP über die Netzwerkadressenübersetzung (Network Adress Translation, NAT). Azure CNI übersetzt die Quell-IP (Überlagerungs-IP des Pods) des Datenverkehrs in die primäre IP-Adresse des virtuellen Computers, sodass der Azure-Netzwerkstapel den Datenverkehr an das Ziel weiterleiten kann. Endpunkte außerhalb des Clusters können keine direkte Verbindung mit einem Pod herstellen. Sie müssen die Anwendung des Pods als Kubernetes-Load Balancer-Dienst veröffentlichen, um sie im VNet erreichbar zu machen.

Sie können die ausgehende Konnektivität zum Internet für Überlagerungspods mithilfe eines Standard-SKU-Load Balancers oder eines verwalteten NAT Gateways bereitstellen. Sie können den ausgehenden Datenverkehr auch steuern, indem Sie ihn mithilfe von benutzerdefinierten Routen im Cluster-Subnetz an eine Firewall weiterleiten.

Sie können die eingehende Konnektivität zu dem Cluster mithilfe eines Eingangsdatencontrollers wie Nginx- oder per HTTP-Anwendungsrouting erreichen. Sie können die eingehende Konnektivität nicht mithilfe von Azure App Gateways konfigurieren. Ausführliche Informationen finden Sie unter Einschränkungen bei Azure CNI Overlay.

Unterschied zwischen Kubenet und Azure CNI Overlay

Die folgende Tabelle enthält einen detaillierten Vergleich zwischen Kubenet und Azure CNI Overlay.

Bereich	Azure CNI Overlay	kubenet
Clusterstaffelung	5000 Knoten und 250 Pods/Knoten	400 Knoten und 250 Pods/Knoten
Netzwerkkonfiguration	Einfach – keine zusätzliche Konfiguration für Pod-Netzwerke erforderlich	Komplex – erfordert Routingtabellen und UDRs im Cluster-Subnetz für Podnetzwerke
Pod-Konnektivitätsleistung	Leistung wie bei VMs in einem VNet	Geringere Latenz durch zusätzlichen Hop
Kubernetes-Netzwerkrichtlinien	Azure-Netzwerkrichtlinien, Calico, Cilium	Calico
Unterstützte Betriebssystemplattformen	Linux und Windows Server 2022, 2019	Nur Linux

IP-Adressplanung

Clusterknoten

Stellen Sie beim Einrichten Ihres AKS-Clusters sicher, dass Ihre VNet-Subnetze über genügend Platz für die zukünftige Skalierung verfügt. Sie können jedem Knotenpool ein dediziertes Subnetz zuweisen.

Beachten Sie, dass ein /24Subnetz bis zu 251 Knoten umfassen kann, da die ersten drei IP-Adressen für Verwaltungsaufgaben reserviert sind.

Pods

Die Überlagerungslösung weist jedem Knoten aus dem privaten CIDR, den Sie während der Clustererstellung angeben, einen /24-Adressraum für Pods zu. Die /24-Größe ist feststehend und kann nicht erhöht oder verringert werden. Sie können auf einem Knoten bis zu 250 Pods ausführen.

Berücksichtigen Sie beim Planen des IP-Adressraums für Pods die folgenden Faktoren:

• Stellen Sie sicher, dass das private CIDR groß genug ist, um /24 Adressräume für neue Knoten bereitzustellen, um zukünftige Clustererweiterungen zu unterstützen.
• Derselbe Pod CIDR-Raum kann auf mehreren unabhängigen AKS-Clustern im gleichen VNet verwendet werden.
• Pod CIDR-Speicherplatz darf sich nicht mit dem Cluster-Subnetzbereich überlappen.
• Pod-CIDR-Speicherplatz darf sich nicht mit direkt verbundenen Netzwerken (z. B. VNET-Peering, ExpressRoute oder VPN) überschneiden. Wenn externer Datenverkehr Quell-IPs im podCIDR-Bereich aufweist, muss er über SNAT in eine nicht überlappende IP-Adresse übersetzt werden, um mit dem Cluster zu kommunizieren.

Kubernetes-Dienstadressbereich

Die Größe der Dienstadresse CIDR hängt von der Anzahl der Clusterdienste ab, die Sie erstellen möchten. Sie muss kleiner als /12 sein. Dieser Bereich sollte sich nicht mit dem Pod-CIDR-Bereich, dem Cluster-Subnetzbereich und dem IP-Bereich überlappen, der in VNets mit Peering und lokalen Netzwerken verwendet wird.

Kubernetes-DNS-Dienst – IP-Adresse

Diese IP-Adresse im Kubernetes-Dienstadressbereich wird bei der Clusterdienstermittlung verwendet. Verwenden Sie nicht die erste IP-Adresse in Ihrem Adressbereich, da diese Adresse für die kubernetes.default.svc.cluster.local-Adresse verwendet wird.

Netzwerksicherheitsgruppen

Pod-zu-Pod-Datenverkehr mit Azure CNI Overlay ist nicht gekapselt, und Subnetzregeln für die Netzwerksicherheitsgruppe finden Anwendung. Wenn die Subnetz-NSG Ablehnungsregeln enthält, die sich auf den Pod-CIDR-Datenverkehr auswirken würden, stellen Sie sicher, dass die folgenden Regeln vorhanden sind, um die ordnungsgemäße Clusterfunktionalität sicherzustellen (zusätzlich zu allen AKS-Ausgangsanforderungen):

• Datenverkehr vom Knoten-CIDR zum Knoten-CIDR an allen Ports und Protokollen
• Datenverkehr vom Knoten-CIDR zum Pod-CIDR an allen Ports und Protokollen (erforderlich für das Routing von Dienstdatenverkehr)
• Datenverkehr vom Pod-CIDR zum Pod-CIDR an allen Ports und Protokollen (erforderlich für den Pod-zu-Pod- und Pod-zu-Dienst-Datenverkehr, einschließlich DNS)

Der Datenverkehr von einem Pod zu einem beliebigen Ziel außerhalb des Pod-CIDR-Blocks verwendet SNAT, um die Quell-IP auf die IP-Adresse des Knotens festzulegen, auf dem der Pod ausgeführt wird.

Wenn Sie den Datenverkehr zwischen Workloads im Cluster einschränken möchten, empfehlen wir die Verwendung von Netzwerkrichtlinien.

Maximale Pods pro Knoten

Sie können die maximale Anzahl an Pods pro Knoten zum Zeitpunkt der Clustererstellung oder beim Hinzufügen eines neuen Knotenpools konfigurieren. Der Standardwert und der Maximalwert für Azure CNI Overlay beträgt 250, und der Mindestwert ist 10. Die maximale Anzahl an Pods pro Knotenwert, die während der Erstellung eines Knotenpools konfiguriert werden, gilt nur für die Knoten in diesem Knotenpool.

Auswählen eines zu verwendenden Netzwerkmodells

Azure CNI bietet zwei IP-Adressierungsoptionen für Pods: die herkömmliche Konfiguration, die VNet-IP-Adressen zu Pods zuweist, und das Überlagerungsnetzwerk. Die Wahl der für Ihren AKS-Cluster zu verwendenden Option ist ein Kompromiss zwischen Flexibilität und erweiterten Konfigurationsanforderungen. Die folgenden Überlegungen helfen bei der Entscheidung, welches Netzwerkmodell am besten geeignet ist.

Verwenden Sie Überlagerungsnetzwerke, wenn Folgendes zutrifft:

• Sie möchten auf eine große Anzahl an Pods skalieren, aber verfügen in Ihrem VNet nur über einen begrenzten IP-Adressraum.
• Die Podkommunikation findet überwiegend innerhalb des Clusters statt.
• Erweiterte AKS-Features wie z. B. virtuelle Knoten sind nicht erforderlich.

Verwenden Sie die herkömmliche VNet-Option, wenn Folgendes zutrifft:

• Sie haben genügend verfügbaren IP-Adressraum.
• Podkommunikation findet überwiegend mit außerhalb des Clusters befindlichen Ressourcen statt.
• Ressourcen außerhalb des Clusters müssen Pods direkt erreichen.
• Sie benötigen erweiterte AKS-Features wie z. B. virtuelle Knoten.

Einschränkungen bei Azure CNI Overlay

Die Azure CNI-Überlagerung weist die folgenden Einschränkungen auf:

• Sie können Application Gateway nicht als Eingangscontroller (AGIC) verwenden.
• Virtual Machine Availability Sets (VMAS) werden nicht unterstützt.
• Sie können keine virtuellen Computer der DCsv2-Serie in Knotenpools verwenden. Um die Anforderungen des vertraulichen Computings zu erfüllen, sollten Sie stattdessen vertrauliche VMs der DCasv5- oder DCadsv5-Serie verwenden.
• Falls Sie ihr eigenes Subnetz zum Bereitstellen des Clusters verwenden, dürfen die Namen der Subnetz-, VNet- und Ressourcengruppe, die das VNet enthält, maximal 63 Zeichen lang sein. Diese Namen werden als Bezeichnungen in AKS-Workerknoten verwendet und unterliegen Kubernetes-Bezeichnungssyntaxregeln.