Freigeben über

Azure Container Networking Interface-Podsubnetz (CNI)

  • Artikel

Das Azure CNI-Podsubnetz weist Pods IP-Adressen aus einem separaten Subnetz von Ihren Clusterknoten zu. Dieses Feature ist in zwei Modi verfügbar: Dynamische IP-Zuordnung und statische Blockzuweisung (Vorschau).

Voraussetzungen

Hinweis

Bei Verwendung der statische Blockzuordnung von CIDR wird das Verfügbarmachen einer Anwendung als Private Link-Dienst mithilfe eines Kubernetes Load Balancer-Diensts nicht unterstützt.

  • Überprüfen Sie die Voraussetzungen für die Konfiguration grundlegender Azure CNI-Netzwerke in AKS, da die gleichen Voraussetzungen für diesen Artikel gelten.

  • Überprüfen Sie die Bereitstellungsparameter zum Konfigurieren grundlegender Azure CNI-Netzwerke in AKS, da dieselben Parameter gelten.

  • AKS-Engine-Cluster und selbst erstellte Cluster werden nicht unterstützt.

  • Azure CLI-Version 2.37.0 oder höher und die aks-preview-Erweiterungsversion 2.0.0b2 oder höher.

  • Registrieren Sie das Featureflag auf Abonnementebene für Ihr Abonnement: „Microsoft.ContainerService/AzureVnetScalePreview“

  • Wenn Sie über einen vorhandenen Cluster verfügen, müssen Sie Container Insights für die Überwachung des Add-Ons für die IP-Subnetznutzung aktivieren. Sie können Container Insights mithilfe des Befehls az aks enable-addons aktivieren, wie im folgenden Beispiel zu sehen:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Modus für die Dynamische IP-Zuordnung

Die dynamische IP-Zuordnung hilft bei der Minderung von Pod-IP-Adressauslastungsproblemen, indem Pod-IPs aus einem Subnetz zugeordnet werden, das vom Subnetz getrennt ist, das den AKS-Cluster hostet.

Der Modus für die dynamische IP-Zuordnung bietet die folgenden Vorteile:

  • Bessere Auslastung von IP-Adressen: IP-Adressen werden Clusterpods dynamisch aus dem Podsubnetz zugeordnet. Dies führt zu einer besseren Auslastung der IP-Adressen im Cluster im Vergleich zur herkömmlichen CNI-Lösung, bei der die IP-Adressen für jeden Knoten statisch zugeordnet werden.
  • Skalierbar und flexibel: Knoten- und Podsubnetze können unabhängig voneinander skaliert werden. Ein einzelnes Podsubnetz kann für mehrere Knotenpools eines Clusters oder mehrere AKS-Cluster im selben VNET freigegeben werden. Sie können auch ein separates Podsubnetz für einen Knotenpool konfigurieren.
  • Hochleistung: Da Pods VNet-IP-Adressen zugewiesen sind, besteht eine direkte Verbindung zu anderen Clusterpods und -ressourcen im VNET. Die Lösung unterstützt selbst größte Cluster ohne Leistungseinbußen.
  • Separate VNET-Richtlinien für Pods: Da für Pods ein separates Subnetz besteht, können Sie auch separate VNET-Richtlinien konfigurieren, die von den Knotenrichtlinien abweichen. Dies ermöglicht viele nützliche Anwendungsfälle wie die Beschränkung der Internetkonnektivität auf Pods statt auf Knoten, das Korrigieren der Quell-IP für Pods in einem Knotenpool mithilfe einer Azure NAT Gateway-Instanz und den Einsatz von Netzwerksicherheitsgruppen (NSGs), um Datenverkehr zwischen Knotenpools zu filtern.
  • Kubernetes-Netzwerkrichtlinien: Sowohl die Azure-Netzwerkrichtlinien als auch Calico sind mit diesem Modus kompatibel.

Planen der IP-Adressierung

Mit der dynamischen IP-Zuweisung skalieren Knoten und Pods unabhängig voneinander, sodass Sie deren Adressräume separat planen können. Da Podsubnetze auf die Granularität eines Knotenpools konfiguriert werden können, können Sie immer ein neues Subnetz hinzufügen, wenn Sie einen Knotenpool hinzufügen. Die Systempods in einem Cluster- bzw. Knotenpool erhalten die IP-Adressen ebenfalls aus dem Podsubnetz, sodass dieses Verhalten berücksichtigt werden muss.

IP-Adressen werden den Knoten in Batches von 16 zugewiesen. Die IP-Zuordnung für das Subnetz eines Pods sollte so geplant werden, dass mindestens 16 IP-Adressen pro Knoten im Cluster zur Verfügung stehen, da die Knoten beim Start 16 IP-Adressen anfordern und weitere 16 jedes Mal dann, wenn in ihrem Kontingent noch <8 IP-Adressen frei sind.

Die IP-Adressenplanung für Kubernetes-Dienste und Docker-Bridges bleibt unverändert.

Modus für die statische Blockzuordnung (Vorschau)

Die statische Blockzuordnung trägt dazu bei, potenzielle Einschränkungen bei der Podsubnetzgröße und der Azure-Adresszuordnung zu minimieren, indem CIDR-Blöcke Knoten anstatt einzelnen IPs zugewiesen werden.

Der Modus für die statische Blockzuordnung bietet die folgenden Vorteile:

  • Bessere IP-Skalierbarkeit: CIDR-Blöcke werden den Clusterknoten statisch zugeordnet und bleiben über die gesamte Lebensdauer des Knotens bestehen, im Gegensatz zur herkömmlichen dynamischen Zuweisung einzelner IPs bei der herkömmlichen CNI. Dies ermöglicht ein Routing auf der Grundlage von CIDR-Blöcken und hilft bei der Skalierung der Clustergrenze von den herkömmlichen 65.000 Pods pro Cluster auf bis zu 1 Million Pods. Ihr Microsoft Azure Virtual Network muss groß genug sein, um der Skalierung Ihres Clusters gerecht zu werden.
  • Flexibilität: Knoten und Pod-Subnetze können unabhängig voneinander skaliert werden. Ein einzelnes Podsubnetz kann für mehrere Knotenpools eines Clusters oder mehrere AKS-Cluster im selben VNET freigegeben werden. Sie können auch ein separates Podsubnetz für einen Knotenpool konfigurieren.
  • Höchstleistung: Da Pods VNet-IP-Adressen zugewiesen werden, besteht eine direkte Verbindung zu anderen Clusterpods und -ressourcen im VNet.
  • Separate VNET-Richtlinien für Pods: Da für Pods ein separates Subnetz besteht, können Sie auch separate VNET-Richtlinien konfigurieren, die von den Knotenrichtlinien abweichen. Das ermöglicht viele nützliche Anwendungsfälle wie die Beschränkung der Internetkonnektivität auf Pods statt auf Knoten, das Korrigieren der Quell-IP für Pods in einem Knotenpool mithilfe einer Azure NAT Gateway-Instanz und den Einsatz von Netzwerksicherheitsgruppen, um Datenverkehr zwischen Knotenpools zu filtern.
  • Kubernetes-Netzwerkrichtlinien: Cilium, Azure NPM und Calico arbeiten mit dieser Lösung.

Begrenzungen

Nachfolgend sind einige Einschränkungen der Verwendung der statische Blockzuordnung von Azure CNI aufgeführt:

  • Erforderliche Kubernetes-Mindestversion: 1.28
  • Maximal unterstützte Subnetzgröße: x.x.x.x/12 ~ 1 Million IPs
  • Pro Subnetz kann nur ein einzelner Betriebsmodus verwendet werden. Wenn ein Subnetz den statischen Blockzuordnungsmodus verwendet, kann in einem anderen Cluster oder Knotenpool mit demselben Subnetz nicht der dynamische IP-Zuordnungsmodus verwendet werden und umgekehrt.
  • Wird nur in neuen Clustern oder beim Hinzufügen von Knotenpools mit einem anderen Subnetz zu vorhandenen Clustern unterstützt. Das Migrieren oder Aktualisieren vorhandener Cluster oder Knotenpools wird nicht unterstützt.
  • Aus allen CIDR-Blöcken, die einem Knoten im Knotenpool zugewiesen sind, wird eine IP als primäre IP des Knotens ausgewählt. Daher sollten Netzwerkadministratoren und Netzwerkadministratorinnen bei der Auswahl des --max-pods-Wertes versuchen, die nachstehende Berechnung zu verwenden, um Ihre Anforderungen bestmöglich zu erfüllen und eine optimale Nutzung der IPs im Subnetz zu erreichen:

max_pods = (N * 16) - 1, wobei N eine beliebige positive ganze Zahl ist und N> 0

Regionale Verfügbarkeit

Diese Funktion ist in den folgenden Regionen nicht verfügbar:

  • USA (Süden)
  • USA (Ost) 2
  • USA (Westen)
  • USA, Westen 2

Planen der IP-Adressierung

Mit der statischen IP-Blockzuweisung skalieren Knoten und Pods unabhängig voneinander, sodass Sie deren Adressräume separat planen können. Da Podsubnetze auf die Granularität eines Knotenpools konfiguriert werden können, können Sie immer ein neues Subnetz hinzufügen, wenn Sie einen Knotenpool hinzufügen. Die Systempods in einem Cluster- bzw. Knotenpool erhalten die IP-Adressen ebenfalls aus dem Podsubnetz, sodass dieses Verhalten berücksichtigt werden muss.

CIDR-Blöcke werden von jeweils /28 (16 IP-Adressen) den Knoten basierend auf der --max-pods-Konfiguration für Ihren Knotenpool, die die maximale Anzahl von Pods pro Knoten definiert, zugewiesen. Auf jedem Knoten ist 1 IP-Adresse aus allen auf diesem Knoten verfügbaren IP-Adressen für interne Zwecke reserviert.

Bei der Planung Ihrer IPs ist es wichtig, Ihre --max-pods-Konfiguration mithilfe der folgenden Berechnung zu definieren: max_pods_per_node = (16 * N) - 1, wobei N eine positive ganze Zahl größer als 0 ist.

Bei idealen Werten ohne Verlust von IP-Adressen müsste der max-pods-Wert dem obigen Ausdruck entsprechen.

Sehen Sie sich die folgenden Beispielfälle an:

Beispielfall max_pods Pro Knoten zugewiesene CIDR-Blöcke Für Pods verfügbare Gesamt-IP IP-Verschwendung für Knoten
Niedrige Verschwendung (akzeptabel) 30 2 (16 × 2) - 1 = 32 - 1 = 31 31 - 30 = 1
Idealfall 31 2 (16 × 2) - 1 = 32 - 1 = 31 31 - 31 = 0
Hohe Verschwendung (nicht empfohlen) 32 3 (16 × 3) - 1 = 48 - 1 = 47 47 - 32 = 15

Die IP-Adressplanung für Kubernetes-Dienste bleibt unverändert.

Hinweis

Stellen Sie sicher, dass Ihr VNet über einen ausreichend großen und zusammenhängenden Adressraum verfügt, um die Skalierung Ihres Clusters unterstützen zu können.