Übersicht über die CNI-Netztechnologie in Azure Kubernetes Service (AKS)
Artikel
Kubernetes verwendet CNI-Plug-Ins (Container Networking Interface), um die Netztechnologie in Kubernetes-Clustern zu verwalten. CNIs sind für das Zuweisen von IP-Adressen zu Pods, Netzwerkrouting zwischen Pods, Kubernetes Service-Routing und mehr verantwortlich.
AKS stellt mehrere CNI-Plug-Ins bereit, die Sie in Ihren Clustern je nach Ihren Netzwerkanforderungen verwenden können.
Netztechnologiemodelle in AKS
Die Auswahl eines CNI-Plug-Ins für Ihren AKS-Cluster hängt weitgehend davon ab, welches Netztechnologiemodell Ihren Anforderungen am besten entspricht. Jedes Modell hat seine eigenen Vor- und Nachteile, die Sie bei der Planung Ihres AKS-Clusters berücksichtigen sollten.
AKS verwendet zwei Hauptnetztechnologiemodelle: Überlagerungsnetzwerk und flaches Netzwerk.
Beide Netztechnologiemodelle verfügen über mehrere unterstützte CNI-Plug-In-Optionen. Die Hauptunterschiede zwischen den Modellen sind die Zuweisung von POD-IP-Adressen und die Zuweisung von Datenverkehr zum Cluster.
Überlagerungsnetzwerke
Überlagerungsnetzwerke sind das am häufigsten verwendete Netztechnologiemodell in Kubernetes. In Überlagerungsnetzwerken erhalten Pods eine IP-Adresse von einem privaten, logisch getrennten CIDR vom Azure VNet-Subnetz, in dem AKS-Knoten bereitgestellt werden. Dies ermöglicht eine einfachere und oft bessere Skalierbarkeit als das flache Netzwerkmodell.
In Überlagerungsnetzwerken können Pods direkt miteinander kommunizieren. Datenverkehr, der den Cluster verlässt, wird per SNAT (Source Network Address Translation, Übersetzung in die Quellnetzwerkadresse) in die IP-Adresse des Knotens übersetzt, und eingehender Pod-IP-Datenverkehr wird über einen bestimmten Dienst weitergeleitet, z. B. einen Lastenausgleich. Dies bedeutet, dass die Pod-IP-Adresse hinter der IP-Adresse des Knotens „ausgeblendet“ ist. Dieser Ansatz reduziert die Anzahl der für Ihre Cluster erforderlichen VNet-IP-Adressen.
Azure Kubernetes Service stellt die folgenden CNI-Plug-Ins für Überlagerungsnetzwerke bereit:
Azure CNI Overlay, das empfohlene CNI-Plug-In für die meisten Szenarios
Im Gegensatz zu einem Überlagerungsnetzwerk weist ein flaches Netzwerkmodell in AKS Pods die IP-Adressen von einem Subnetz aus demselben Azure VNet wie die AKS-Knoten zu. Dies bedeutet, dass Datenverkehr, der Ihre Cluster verlässt, nicht per SNAT behandelt wird und die Pod-IP-Adresse direkt für das Ziel verfügbar gemacht wird. Dies kann für einige Szenarios nützlich sein, z. B. wenn Sie Pod-IP-Adressen für externe Dienste verfügbar machen müssen.
Azure Kubernetes Service bietet zwei CNI-Plug-Ins für flache Netzwerke. In diesem Artikel werden die einzelnen Plug-In-Optionen nicht ausführlich behandelt. Weitere Informationen finden Sie in der verlinkten Dokumentation:
Azure CNI-Knotensubnetz, ein älteres CNI für flache Netzwerkmodelle, wird im Allgemeinen nur empfohlen, wenn Sie ein verwaltetes VNet für Ihren Cluster benötigen.
Auswählen eines CNI
Bei der Auswahl eines CNI gibt es mehrere Faktoren zu berücksichtigen. Jedes Netzwerkmodell hat seine eigenen Vor- und Nachteile, und die beste Wahl für Ihren Cluster hängt von Ihren spezifischen Anforderungen ab.
Auswählen eines Netztechnologiemodells
Die beiden wichtigsten Netzwerkmodelle in AKS sind Überlagerungsnetzwerke und flache Netzwerke.
Überlagerungsnetzwerke:
Sparen Sie den VNet-IP-Adressraum, indem Sie logisch getrennte CIDR-Bereiche für Pods verwenden.
Unterstützung der maximalen Clusterstaffelung
Einfache IP-Adressverwaltung
Flache Netzwerke:
Pods erhalten vollständige VNet-Konnektivität und können direkt über die private IP-Adresse aus verbundenen Netzwerken erreicht werden.
Erfordert einen großen, nicht fragmentierten VNet-IP-Adressraum
Anwendungsfallvergleich
Berücksichtigen Sie bei der Auswahl eines Netztechnologiemodells die Anwendungsfälle für jedes CNI-Plug-In und den Typ des verwendeten Netzwerkmodells:
CNI-Plug-In
Netzwerkmodell
Highlights der Anwendungsfälle
Azure CNI Overlay
Überlagerung
– Optimal für die VNET-IP-Erhaltung – Maximale Knotenanzahl, die vom API-Server und 250 Pods pro Knoten unterstützt wird – Einfachere Konfiguration – Kein direkter externer Pod-IP-Zugriff
Azure CNI-Podsubnetz
Flach
– Direkter externe Podzugriff – Modi für eine effiziente VNet-IP-Nutzung oder Unterstützung für große Cluster
Kubenet (Legacy)
Überlagerung
– Priorisiert die IP-Erhaltung – Begrenzte Skalierung – Manuelle Routenverwaltung
Sie können auch die Features der einzelnen CNI-Plug-Ins vergleichen. Die folgende Tabelle enthält einen allgemeinen Vergleich der Features, die von den einzelnen CNI-Plug-Ins unterstützt werden:
Funktion
Azure CNI Overlay
Azure CNI-Podsubnetz
Azure CNI-Knotensubnetz (Legacy)
Kubenet
Bereitstellen des Clusters in vorhandenem oder neuem VNet
Unterstützt
Unterstützt
Unterstützt
Unterstützt – manuelle UDRs
Pod-VM-Konnektivität mit vm in demselben VNet oder Peer-VNet
Pod initiiert
Beide Richtungen
Beide Richtungen
Pod initiiert
Lokaler Zugriff über VPN/Express Route
Pod initiiert
Beide Richtungen
Beide Richtungen
Pod initiiert
Zugriff auf Dienstendpunkte
Unterstützt
Unterstützt
Unterstützt
Unterstützt
Verfügbarmachen von Diensten mithilfe des Lastenausgleichs
Unterstützt
Unterstützt
Unterstützt
Unterstützt
Verfügbarmachen von Diensten mithilfe von App Gateway
Wird derzeit nicht unterstützt.
Unterstützt
Unterstützt
Unterstützt
Verfügbarmachen von Diensten mit dem Eingangsdatencontroller
Unterstützt
Unterstützt
Unterstützt
Unterstützt
Windows-Knotenpools
Unterstützt
Unterstützt
Unterstützt
Nicht unterstützt
Standard: Azure DNS und private Zonen
Unterstützt
Unterstützt
Unterstützt
Unterstützt
VNet-Subnetzfreigabe über mehrere Cluster
Unterstützt
Unterstützt
Unterstützt
Nicht unterstützt
Supportumfang der Netzwerkmodelle
Je nachdem, welche CNI Sie verwenden, können Ihre virtuellen Clusternetzwerkressourcen auf eine der folgenden Arten bereitgestellt werden:
Die Azure-Plattform kann die Ressourcen des virtuellen Netzwerks automatisch erstellen und konfigurieren, wenn Sie einen AKS-Cluster erstellen. wie im Azure CNI Overlay, Azure CNI-Knotensubnetz und Kubenet.
Sie können die Ressourcen des virtuellen Netzwerks manuell erstellen und konfigurieren und an diese Ressourcen anfügen, wenn Sie Ihren AKS-Cluster erstellen.
Auch wenn Funktionen wie Dienstendpunkte oder benutzerdefinierte Routen (UDRs) unterstützt werden, legen die Supportrichtlinien für AKS fest, welche Änderungen Sie vornehmen können. Zum Beispiel:
Wenn Sie die Ressourcen des virtuellen Netzwerks für einen AKS-Cluster manuell erstellen, werden Sie unterstützt, wenn Sie Ihre eigenen benutzerdefinierten Routen oder Dienstendpunkte konfigurieren.
Wenn die Azure-Plattform die Ressourcen des virtuellen Netzwerks automatisch für Ihren AKS-Cluster erstellt, können Sie diese von AKS verwalteten Ressourcen nicht manuell ändern, um Ihre eigenen benutzerdefinierten Routen oder Dienstendpunkte zu konfigurieren.
Voraussetzungen
Es gibt mehrere Anforderungen und Überlegungen, die Sie bei der Planung der Netzwerkkonfiguration für AKS berücksichtigen sollten:
Das virtuelle Netzwerk des AKS-Clusters muss ausgehende Internetkonnektivität zulassen.
AKS-Cluster können 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 oder 192.0.2.0/24 für den Adressbereich des Kubernetes-Diensts, den Adressbereich für den Pod oder den Adressbereich für das virtuelle Clusternetzwerk nicht verwenden.
In BYO-Szenarios für VNet muss die vom AKS-Cluster verwendete Clusteridentität mindestens die Berechtigung Netzwerkmitwirkender für das Subnetz in Ihrem virtuellen Netzwerk haben. Wenn Sie eine benutzerdefinierte Rolle anstelle der integrierten Rolle des Netzwerkmitwirkenden definieren möchten, sind die folgenden Berechtigungen erforderlich:
Microsoft.Network/virtualNetworks/subnets/read (nur erforderlich, wenn Sie Ihre eigenen Subnetze und CIDRs definieren)
Das Subnetz, das dem AKS-Knotenpool zugewiesen ist, darf kein delegiertes Subnetz sein.
AKS wendet keine Netzwerksicherheitsgruppen (NSGs) auf sein Subnetz an und ändert keine der NSGs, die diesem Subnetz zugeordnet sind. Wenn Sie Ihr eigenes Subnetz bereitstellen und NSGs hinzufügen, die diesem Subnetz zugeordnet sind, müssen Sie sicherstellen, dass die Sicherheitsregeln in den NSGs Datenverkehr im CIDR-Knotenbereich zulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
Feedback zu Azure Kubernetes Service
Azure Kubernetes Service ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben:
Zeigen Sie Ihre Kenntnisse zu Entwurf, Implementierung und Wartung der Azure-Netzwerkinfrastruktur, zum Lastenausgleich für Datenverkehr, zum Netzwerkrouting u. v. m.