Übersicht über die CNI-Netztechnologie in Azure Kubernetes Service (AKS)
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
- kubenet, das ältere Überlagerungsmodell-CNI
Flache Netzwerke
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-Pod-Subnetz, das empfohlene CNI-Plug-In für flache Netzwerkszenarios
- 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 |
| Azure CNI-Knotensubnetz (Legacy) | Flach | – Direkter externe Podzugriff – Einfachere Konfiguration – Begrenzte Skalierung – Ineffiziente Verwendung von VNet-IPs |
Funktionsvergleich
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/16oder192.0.2.0/24fü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/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.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.
Nächste Schritte
Azure Kubernetes Service