Konfigurieren des Azure CNI-Pod-Subnetzes – Statische Blockzuweisung und erweiterte Subnetzunterstützung in Azure Kubernetes Service (AKS)

Eine Einschränkung der dynamischen IP-Zuordnung für das Pod-Subnetz von Azure CNI ist die Skalierbarkeit der Pod-Subnetzgröße über ein /16-Subnetz hinaus. Auch bei einem großen Subnetz sind große Cluster aufgrund eines Azure-Adresszuordnungsgrenzwerts möglicherweise noch auf 65.000 Pods beschränkt. Das Pod-Subnetz – Statische Blockzuordnung in Azure CNI löst dieses Problem durch Zuweisen von CIDR-Blöcken zu Knoten anstelle einzelner IPs.

Dies hat folgende 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.
• Hohe Leistung: Da Pods virtuelle Netzwerk-IPs zugewiesen werden, verfügen sie über direkte Konnektivität zu anderen Cluster-Pods 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 neuen Lösung.

In diesem Artikel erfahren Sie, wie Sie Azure CNI Pod Subnet – Static Block Allocation und erweiterte Subnetzunterstützung in AKS verwenden.

Prerequisites

• Ü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.75.0 oder höher

• Wenn Sie über einen vorhandenen Cluster verfügen, müssen Sie Container Insights für die Überwachung der 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>
  

Limitations

Nachfolgend sind einige der Einschränkungen der Verwendung von Azure CNI Pod Subnet - Static Block Allocation 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 Modus "Statische Blockzuordnung" verwendet, kann er den Dynamischen IP-Zuordnungsmodus nicht in einem anderen Cluster oder Knotenpool mit demselben Subnetz verwenden 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 und N > 0 ist

Planen der IP-Adressierung

Die Planung Ihrer IP-Adressierung ist flexibler und präziser. Da die Knoten und Pods unabhängig voneinander skaliert werden, können auch ihre Adressräume separat geplant werden. 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.

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

Bei der Festlegung und Planung Ihrer IPs ist es daher unerlässlich, Ihre „--max-pods“-Konfiguration zu definieren, die sich am besten wie folgt berechnen lässt: 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.

• Beispiel 1: max_pods = 30, pro Knoten zugewiesene CIDR-Blöcke = 2, Gesamt-IPs für Pods = (16 * 2) - 1 = 32 - 1 = 31, IP-Verschwendung pro Knoten = 31 - 30 = 1 [Niedrige Verschwendung - Akzeptabler Fall]
• Beispiel 2: max_pods = 31, PRO Knoten zugewiesene CIDR-Blöcke = 2, Gesamt-IPs für Pods = (16 * 2) - 1 = 32 - 1 = 31, IP-Verschwendung pro Knoten = 31 - 31 = 0 [Idealfall]
• Beispiel 3: max_pods = 32, pro Knoten zugewiesene CIDR-Blöcke = 3, Gesamtanzahl der IP-Adressen für Pods = (16 * 3) - 1 = 48 - 1 = 47, IP-Verschwendung pro Knoten = 47 - 32 = 15 [Hohe Verschwendung - Nicht empfohlener Fall]

Die Planung von Ip-Adressen für Kubernetes-Dienste bleibt unverändert.

Bereitstellungsparameter

Die Bereitstellungsparameter zum Konfigurieren grundlegender Azure CNI-Netzwerke in AKS sind alle gültig, mit Ausnahmen:

• Der Parameter vnet subnet id verweist jetzt auf das Subnetz für die Knoten des Clusters.
• Der Parameter pod subnet id wird verwendet, um das Subnetz anzugeben, dessen IP-Adressen statisch oder dynamisch Pods im Knotenpool zugeordnet werden.
• Der Parameter pod ip allocation mode bestimmt, ob DynamicIndividual (dynamische IP-Zuweisung) oder StaticBlock (statische Blockzuweisung) verwendet werden soll.

Konfigurieren von Netzwerken mit statischer Zuordnung von CIDR-Blöcken und erweiterter Subnetzunterstützung – Azure CLI

Die Verwendung von Pod Subnet - Static Block Allocation in Ihrem Cluster ähnelt der Standardmethode zum Konfigurieren eines Clusters mit Pod Subnet - Dynamic IP Allocation. Im folgenden Beispiel wird das Erstellen eines neuen virtuellen Netzwerks mit einem Subnetz für Knoten und einem Subnetz für Pods und das Erstellen eines Clusters beschrieben, der Azure CNI Pod Subnet - Static Block Allocation verwendet. Ersetzen Sie die Variablen wie $subscription durch geeignete Werte.

Erstellen Sie das virtuelle Netzwerk mit zwei Subnetzen.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none 

Erstellen Sie den Cluster, wobei Sie mit --vnet-subnet-id auf das Knotensubnetz und mit --pod-subnet-id auf das Pod-Subnetz verweisen, mit --pod-ip-allocation-mode den IP-Adressenzuordnungsmodus definieren und das Add-On für die Überwachung aktivieren.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Hinzufügen des Knotenpools

Verweisen Sie beim Hinzufügen des Knotenpools mit --vnet-subnet-id auf das Subnetz des Knotens, mit --pod-subnet-id auf das Pod-Subnetz und mit „--pod-ip-allocation-mode“ auf den Zuordnungsmodus. Im folgenden Beispiel werden zwei neue Subnetze erstellt, auf die dann bei der Erstellung eines neuen Knotenpools verwiesen wird:

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Migrieren vom Pod-Subnetz – Dynamische IP-Zuweisung zu Pod-Subnetz – Statische Blockzuweisung

Wenn Sie über einen vorhandenen AKS-Cluster verfügen, der die dynamische IP-Zuordnung für das Pod-Subnetz verwendet und zu Pod-Subnetz migrieren möchten – statische Blockzuweisung, führen Sie die folgenden Schritte aus:

Schritte der Migration

1. Planen eines neuen Subnetzes, das für statische Block-Agentpools verwendet werden soll

   • Erstellen Sie ein neues Subnetz in Ihrem vorhandenen VNet, das dem statischen Blockmodus zugeordnet ist.
   • Stellen Sie sicher, dass die Subnetzgröße den Im Abschnitt "Planen der IP-Adressierung " beschriebenen Planungsrichtlinien folgt.

2. Hinzufügen eines Agentpools zu Ihrem vorhandenen Cluster mit statischem Blockmodus und dem neuen Subnetz

   • Verwenden des az aks nodepool add Befehls zum Erstellen eines neuen Knotenpools mit statischer Blockzuordnung
   • Verweisen Sie auf das neue Subnetz mit --pod-subnet-id und setzen Sie --pod-ip-allocation-mode auf StaticBlock

3. Grenzen Sie Ihren vorhandenen Agentpool ab, damit alle Ihre Bereitstellungen und der Netzwerkverkehr auf den neuen Agentpool übertragen werden

   • Verwenden Sie kubectl cordon, um vorhandene Knoten als nicht planbar zu kennzeichnen.
   • Schrittweise Arbeitsauslastungen aus dem alten Knotenpool in den neuen statischen Blockknoten-Pool verlagern.

4. Nachdem alle Workloads in den neuen Agentpool verschoben wurden, löschen Sie den vorhandenen nicht statischen Block-Agent-Pool.

   • Überprüfen, ob alle Workloads erfolgreich im neuen Knotenpool ausgeführt werden
   • Entfernen des alten Knotenpools mithilfe von az aks nodepool delete

FAQ zur statischen Zuordnung von CIDR-Blöcken und zur erweiterten Subnetzunterstützung

• Kann ich einem Cluster mehrere Pod-Subnetze zuweisen?

  Einem Cluster können mehrere Subnetze zugewiesen werden, doch kann jedem Knotenpool nur ein Subnetz zugewiesen werden. Verschiedene Knotenpools innerhalb desselben/unterschiedlicher Cluster können dasselbe Subnetz gemeinsam nutzen.

• Kann ich Podsubnetze auch aus unterschiedlichen VNETs zuweisen?

  Nein, das Podsubnetz muss demselben VNet angehören wie der Cluster.

• Können einige Knotenpools in einem Cluster mit Pod-Subnetz-IPAM dynamische IP-Zuordnung verwenden, während andere die neue statische Blockzuweisung verwenden?

  Ja, unterschiedliche Knotenpools können unterschiedliche Zuordnungsmodi verwenden. Sobald ein Subnetz jedoch in einem Zuordnungsmodus verwendet wird, kann es in allen ihm zugeordneten Knotenpools nur im selben Zuordnungsmodus verwendet werden.

Nächste Schritte

Weitere Informationen zu Netzwerken in AKS finden Sie in den folgenden Artikeln:

• Verwenden einer statischen IP-Adresse mit dem Lastenausgleich von Azure Kubernetes Service (AKS)
• Verwenden eines internen Lastenausgleichs mit Azure Kubernetes Service (AKS)
• Verwenden Sie das Add-On für das Anwendungsrouting in Azure Kubernetes Service (AKS)