Auf Englisch lesen

Freigeben über

Ü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.

Ein Diagramm mit zwei Knoten mit drei Pods, die jeweils in einem Überlagerungsnetzwerk ausgeführt werden. Pod-Datenverkehr zu Endpunkten außerhalb des Clusters wird per NAT weitergeleitet.

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.

Ein Diagramm mit zwei Knoten mit drei Pods, die jeweils in einem flachen Netzwerkmodell ausgeführt werden

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/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/join/action
    • Microsoft.Authorization/roleAssignments/write
    • 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.

Nächste Schritte