Überblick über das CNI-Netzwerk in Azure Kubernetes Service (AKS)

Kubernetes verwendet CNI-Plug-Ins (Container Networking Interface), um die Netztechnologie in Kubernetes-Clustern zu verwalten. CNI-Plug-Ins behandeln das Zuweisen von IP-Adressen zu Pods, das Routing des Netzwerkdatenverkehrs zwischen Pods, das Routing von Kubernetes-Dienstdatenverkehr und vieles mehr.

Azure Kubernetes Service (AKS) bietet je nach Ihren Netzwerkanforderungen mehrere CNI-Netzwerkkonfigurationen, die Sie in Ihren Clustern verwenden können. Wenn Sie pod networking planen, wählen Sie eine IP-Adressverwaltungsoption (IPAM) und eine Routing- und Transporttechnologie für die Netzwerkdatenebene aus.

Netzwerkmodelle in AKS

Die Auswahl einer IPAM-Option für Ihren AKS-Cluster hängt weitgehend davon ab, welches Netzwerkmodell 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 Hauptnetzwerkmodelle:

• Überlagerungsnetzwerk:

  • Spart IP-Adressraum für virtuelle Netzwerke (VNets) durch die Verwendung logisch getrennter Classless Inter-Domain Routing (CIDR)-Bereiche für Pods.
  • Bietet maximale Unterstützung für die Skalierung von Clustern.
  • Bietet eine einfache Verwaltung von IP-Adressen.

• Flaches Netzwerk:

  • Stellt vollständige VNet-Konnektivität für Pods bereit. Pods können über ihre private IP-Adresse über verbundene Netzwerke direkt erreicht werden.
  • Erfordert großen, nicht fragmentierten IP-Adressraum für VNets.

Beide Netzwerkmodelle unterstützen mehrere IPAM-Optionen. Die hauptunterschiede zwischen den Modellen sind die Zuweisung von Pod-IP-Adressen und das Verlassen des Clusters durch Datenverkehr.

Für Azure CNI ist die IPAM-Option von der Netzwerkdatenebene getrennt. Sie können die Azure CNI Powered by Cilium-Datenebene mit Azure CNI-Überlagerung, Azure CNI-Pod-Subnetz oder Azure CNI-Knoten-Subnetz verwenden. Weitere Informationen zu IPAM- und Datenebenenoptionen finden Sie unter Plan pod networking for AKS.

Überlagerungsnetzwerke

Überlagerungsnetzwerke in AKS weisen Pod-IP-Adressen von einem separaten POD-CIDR zu, der sich vom Knotensubnetz im VNet unterscheidet. Diese Konfiguration ermöglicht eine einfachere und oft bessere Skalierbarkeit als das Flache-Netzwerkmodell.

In Überlagerungsnetzwerken können Pods direkt miteinander kommunizieren. Der aus dem Cluster ausgehende Datenverkehr wird mittels Source Network Address Translation (SNAT) in die IP-Adresse des Knotens übersetzt. Eingehender Pod-IP-Datenverkehr wird über einen Dienst weitergeleitet, z. B. einen Load Balancer. Die Pod-IP-Adresse wird dann hinter der IP-Adresse des Knotens "versteckt". Dieser Ansatz reduziert die Anzahl der IP-Adressen, die für virtuelle Netzwerke in Ihren Clustern erforderlich sind.

Für Überlagerungsnetzwerke stellt AKS Azure CNI-Overlay bereit. Verwenden Sie diese IPAM-Option für die meisten Szenarien.

Flache Netzwerke

Im Gegensatz zu einem Überlagerungsnetzwerk weist ein Flaches Netzwerkmodell in AKS Pods aus einem Subnetz im selben Azure virtuellen Netzwerk wie die AKS-Knoten zu. Bei privatem Netzwerkdatenverkehr hängt die ip-Quelladresse, die ein Ziel sieht, von der IPAM-Option ab. Azure CNI Pod Subnet behält die POD-IP-Adresse über verbundene virtuelle Netzwerke bei. Mit Azure CNI Node Subnet sehen Ziele im virtuellen Clusternetzwerk die Pod-IP-Adresse, aber Ziele außerhalb des virtuellen Clusternetzwerks sehen die Knoten-IP-Adresse. Wenn der Internetausgang aktiviert ist, bestimmt die konfigurierte ausgehende Methode des Clusters die ip-Adresse der öffentlichen Quelle, die Internetziele sehen.

AKS bietet zwei Azure CNI IPAM-Optionen für flache Netzwerke:

• Azure CNI Pod Subnet, die empfohlene IPAM-Option für flache Netzwerkszenarien.
• Azure CNI Node Subnet, ein älteres CNI-Modell für flache Netzwerke. Im Allgemeinen wird empfohlen, sie nur zu verwenden, wenn Sie ein verwaltetes virtuelles Netzwerk für Ihren Cluster benötigen.

Auswählen einer IPAM-Option für AKS

Berücksichtigen Sie bei der Auswahl einer IPAM-Option mehrere Faktoren. Jedes Netzwerkmodell hat seine eigenen Vor- und Nachteile. Die beste Wahl für Ihren Cluster hängt von Ihren spezifischen Anforderungen ab.

Anwendungsfallvergleich

Funktionsvergleich

Umfang der Unterstützung zwischen Netzwerkmodellen

Abhängig von der verwendeten IPAM-Option können Sie die virtuellen Netzwerkressourcen für Ihren Cluster auf eine der folgenden Arten bereitstellen:

• Die Azure-Plattform kann beim Erstellen eines AKS-Clusters automatisch die virtuellen Netzwerkressourcen erstellen und konfigurieren.
• 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. 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 für AKS CNI-Netzwerke

Beachten Sie bei der Planung der Netzwerkkonfiguration für AKS die folgenden Anforderungen und Überlegungen:

• Sofern Sie keinen isolierten Netzwerkcluster verwenden, muss das virtuelle Netzwerk für den AKS-Cluster ausgehende Internetverbindung mit erforderlichen Endpunkten zulassen. Isolierte Netzwerkcluster können bootstrap ohne ausgehende Internetverbindung.

• AKS-Adressbereiche haben die folgenden Einschränkungen:

  Reservierter CIDR-Bereich	Gilt für:	Zustand
  169.254.0.0/16	Kubernetes-Dienst-, Pod- und Cluster-Adressbereiche für virtuelle Netzwerke	Alle AKS-Cluster
  192.0.2.0/24	Kubernetes-Dienst-, Pod- und Cluster-Adressbereiche für virtuelle Netzwerke	Alle AKS-Cluster
  172.30.0.0/16	Kubernetes-Dienst-, Pod- und Cluster-Adressbereiche für virtuelle Netzwerke	Alle AKS-Cluster
  172.31.0.0/16	Kubernetes-Dienst-, Pod- und Cluster-Adressbereiche für virtuelle Netzwerke	Alle AKS-Cluster

  AKS lehnt pod CIDRs ab, die einen reservierten Bereich während der Clustererstellung oder -aktualisierung überlappen. Ist beispielsweise ungültig, 172.16.0.0/12 da der Bereich einschließt 172.30.0.0/16 und 172.31.0.0/16.

• In Szenarien, in denen Sie Ihr eigenes virtuelles Netzwerk mitbringen, muss die Clusteridentität, die der AKS-Cluster verwendet, mindestens über Netzwerkmitwirkendeberechtigungen für das Subnetz in Ihrem virtuellen Netzwerk verfügen.

• Wenn Sie eine benutzerdefinierte Rolle definieren, anstatt die integrierte Rolle "Netzwerkmitwirkender" zu verwenden, schließen Sie die folgenden Berechtigungen ein:

  Berechtigung	Wenn erforderlich
  Microsoft.Network/virtualNetworks/subnets/join/action	Immer bei Verwendung einer benutzerdefinierten Rolle
  Microsoft.Authorization/roleAssignments/write	Immer bei Verwendung einer benutzerdefinierten Rolle
  Microsoft.Network/virtualNetworks/subnets/read	Nur beim Definieren Ihrer eigenen Subnetze und CIDRs

• 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 diesem Subnetz zugeordnete NSGs hinzufügen, müssen Sie sicherstellen, dass die Sicherheitsregeln in den NSGs Datenverkehr innerhalb des Knoten-CIDR-Bereichs zulassen. Wenn eine NSG-Verweigerungsregel den Pod CIDR-Datenverkehr betrifft, müssen Sie bei Azure CNI-Überlagerung auch den Datenverkehr vom Knoten CIDR zum Pod CIDR und vom Pod CIDR zum Pod CIDR für alle Ports und Protokolle zulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen mit Azure CNI-Overlay.

• Container Network Service (CNS) ist ein lokaler Knotendienst in Azure Kubernetes Service CNI-Netzwerk, der Netzwerknetzwerke für Pods zuordnet, verfolgt und programmiert. Diese Komponente sendet Telemetrie (Metriken und Protokolle) standardmäßig aus dem Cluster an einen Microsoft verwalteten Application Insights-Endpunkt, um eine schnellere Problembehandlung bei problemen mit der Ip-Adresszuweisung von Pod-Netzwerken zu ermöglichen.

Verwandte Inhalte

• Azure CNI-Überlagerung
• Azure CNI-Podsubnetz
• Legacy-CNI-Optionen
• IP-Adressplanung für Ihre Cluster