Identifizieren von Plug-In-Optionen

  • 5 Minuten

Ein Netzwerk-Plug-In ist für einen AKS-Cluster erforderlich, um Pod-zu-Pod-Kommunikation, Pod-zu-Knoten-Kommunikation und in einigen Fällen die Knoten-zu-Pod-Kommunikation zu ermöglichen. Es gibt zwei Netzwerkmodelle auf AKS: kubenet und Azure CNI. Es gibt zusätzliche Entwicklungen von Azure CNI, einschließlich Azure CNI Overlay, Azure CNI für die dynamische IP-Zuweisung und Azure CNI unterstützt von Cilium. Jedes dieser Modelle verfügt über eigene Features und Einschränkungen.

kubenet

Standardmäßig verwenden AKS-Cluster kubenet. Mit kubenet werden beim Bereitstellen des Clusters automatisch ein virtuelles Azure-Netzwerk, ein Subnetz und eine Routentabelle erstellt, aber auch vorhandene Netzwerkressourcen können bereitgestellt werden. Mit kubenet geschieht Folgendes:

  • Knoten erhalten eine IP-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks.
  • Pods erhalten eine IP-Adresse aus einem logisch anderen Adressraum als dem Subnetz des Knotenpools.
  • Die Netzwerkadressenübersetzung (Network Address Translation, NAT) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können.
  • Die Quell-IP-Adresse des Datenverkehrs wird in die primäre IP-Adresse des Knotens übersetzt.

Pods können nicht direkt miteinander über Knoten hinweg kommunizieren. Stattdessen werden benutzerdefiniertes Routing (User Defined Routing, UDR) und IP-Weiterleitung für die Konnektivität zwischen Pods über Knoten verwendet. Standardmäßig werden UDRs und die IP-Weiterleitungskonfiguration vom AKS-Dienst erstellt und verwaltet, Sie haben jedoch die Möglichkeit, eine eigene Routingtabelle für benutzerdefinierte Routenverwaltung zu verwenden.

Falls Ihr benutzerdefiniertes Subnetz keine Routingtabelle enthält, erstellt AKS automatisch eine Routingtabelle und fügt ihr während des gesamten Clusterlebenszyklus Regeln hinzu. Wenn Ihr benutzerdefiniertes Subnetz bei der Clustererstellung bereits eine Routingtabelle enthält, wird diese bei Clustervorgänge von AKS berücksichtigt, und es werden entsprechende Regeln für Cloudanbietervorgänge hinzugefügt/aktualisiert.

Abbildung: kubenet-Netzwerkmodell mit einem AKS-Cluster; zwei Knoten verwenden kubenet, um Datenverkehr über das Knotensubnetz des virtuellen Netzwerks zu leiten und die Netzwerkadressübersetzung auszuführen

Azure CNI

Das Azure CNI-Plug-In ist eine komplexere Netzwerkoption mit höherer Konfigurierbarkeit und mehr unterstützten Funktionen. Bei Azure CNI sind ein bereits vorhandenes Subnetz und ein virtuelles Netzwerk erforderlich, um die Cluster mit Azure CNI-Netzwerken zu nutzen, was zusätzliche Planung erfordert. Die Größe Ihres virtuellen Netzwerks und des zugehörigen Subnetzes muss die Anzahl von Pods, die ausgeführt werden sollen, und die Anzahl von Knoten für den Cluster abdecken. Mit Azure CNI:

  • Knoten erhalten einen IP-Adressraum aus dem Subnetz des virtuellen Azure-Netzwerks.
  • Jeder Pod empfängt eine IP-Adresse im Subnetz des Knotenpools und kann direkt mit anderen Pods und Diensten kommunizieren.
  • Ihre Cluster können so groß wie der IP-Adressbereich sein, den Sie angeben. Allerdings muss der IP-Adressbereich im Voraus geplant werden, und alle IP-Adressen werden von den AKS-Knoten basierend auf der maximalen Anzahl von Pods genutzt, die sie unterstützen können.

Mit Azure CNI werden ein bereits vorhandenes Subnetz und ein virtuelles Netzwerk benötigt, um das Azure CNI-Netzwerk-Plug-In nutzen zu können. Dieses Subnetz und virtuelle Netzwerk kann zum Zeitpunkt der Erstellung des AKS-Clusters erstellt werden.

Abbildung: Azure CNI-Netzwerkmodell; Pods kommunizieren über eine Brücke; jedem Pod ist eine eindeutige IP-Adresse aus dem Knotensubnetz des virtuellen Netzwerks zugewiesen

Azure CNI Overlay

Azure CNI Overlay stellt eine Weiterentwicklung von Azure CNI dar, mit der Skalierbarkeits- und Planungsherausforderungen behoben werden, die sich aus der Zuweisung von virtuelle Netzwerk IP-Adressen zu Pods ergeben. Azure CNI Overlay weist privaten CIDR-IPs zu Pods zu. Die privaten IPs sind vom virtuellen Netzwerk getrennt und können in mehreren Clustern wiederverwendet werden. Azure CNI Overlay kann über die in Kubenet-Clustern erzwungene Grenze von 400 Knoten hinaus skaliert werden. Azure CNI Overlay wird für die meisten Cluster empfohlen.

Azure CNI Powered by Cilium

Azure CNI Powered by Cilium verwendet Cilium, um leistungsstarke Netzwerke, Einblicke und Netzwerkrichtlinienerzwingung bereitzustellen. Es wird nativ in Azure CNI Overlay für die skalierbare IP-Adressverwaltung (IPAM) integriert.

Darüber hinaus erzwingt Cilium standardmäßig Netzwerkrichtlinien, ohne dass ein separates Netzwerkrichtlinienmodul erforderlich ist. Azure CNI Powered by Cilium kann durch die Verwendung von ePBF-Programmen und einer effizienteren API-Objektstruktur über die Azure Network Policy Manager-Grenzwerte von 250 Knoten/20-K-Pod hinaus skaliert werden.

Azure CNI Powered by Cilium wird für Cluster, die die Durchsetzung von Netzwerkrichtlinien erfordern, empfohlen.

Verwenden eines benutzerdefinierten Plug-Ins

Für Kunden, die eine benutzerdefinierte Netzwerkkonfiguration verwenden möchten, gibt es keine Netzwerk-Plug-In-Anforderungen. Sie können aus CNI-Anbietern wie Cilium oder Flannel wählen. Es empfiehlt sich jedoch, sich an deren Dokumentation zu lesen, da sie nicht von Microsoft abgedeckt werden.