Konfigurieren von Azure CNI-Netzwerken für die dynamische Zuordnung von CIDR-Blöcken und der erweiterten Subnetzunterstützung in Azure Kubernetes Service (AKS).

Eine Einschränkung der dynamischen IP-Zuordnung 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. Die neue Funktion zur statischen Blockzuordnung in Azure CNI löst dieses Problem, indem sie CIDR-Blöcke den Knoten und nicht einzelnen IPs zuweist.

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.
• 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 neuen Lösung.

Dieser Artikel demonstriert, wie Sie Azure CNI-Netzwerke für die dynamische Zuordnung von CIDR und erweiterte Subnetzunterstützung in AKS nutzen.

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 mit der Erweiterung ask-preview der Version 2.0.0b2 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:

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

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

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 und N > 0 ist

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

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 jeweils /28 (16 IP-Adressen) den Knoten basierend auf der „--max-pod“-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 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 [Geringe 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, Gesamt-IPs 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.

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.

Bereitstellungsparameter

Die Bereitstellungsparameter für die Konfiguration grundlegender Azure CNI-Netzwerke in AKS sind alle gültig, mit zwei 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 gibt an, ob dynamisch einzelne Blöcke zugeordnet werden oder die statische Blockzuordnung verwendet werden soll.

Voraussetzungen

• Wenn Sie die Azure CLI verwenden, benötigen Sie die Erweiterung aks-preview. Siehe Installieren Sie die aks-previewAzure CLI-Erweiterung.
• Wenn Sie ARM oder die REST-API verwenden, muss die AKS-API-Version 2024-01-02-preview oder höher entsprechen.

Installieren der Azure CLI-Erweiterung aks-preview

1. Installieren Sie die „aks-preview“-Erweiterung mithilfe des Befehls „az extension add“.

   az extension add --name aks-preview
   

2. Führen Sie mit dem Befehl az extension update ein Update auf die neueste Version der Erweiterung aus. Die Erweiterung sollte die Version „2.0..0b2“ oder höher haben.

   az extension update --name aks-preview
   

Registrieren des AzureVnetScalePreview-Featureflags

1. Registrieren Sie das Featureflag AzureVnetScalePreview mithilfe des Befehls az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
   

   Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.

2. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show.

   az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
   

3. Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

   az provider register --namespace Microsoft.ContainerService
   

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

Die Verwendung der statischen Zuordnung von CIDR-Blöcken in Ihrem Cluster ähnelt der Standardmethode zum Konfigurieren von Azure CNI eines Clusters für die dynamische Zuordnung von IP-Adressen. Das folgende Beispiel veranschaulicht die Erstellung eines neuen virtuellen Netzwerks mit einem Subnetz für Knoten und einem weiteren Subnetz für Pods und die Erstellung eines Clusters, der Azure CNI mit statischer Zuordnung von CIDR-Blöcken 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

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 die dynamische IP-Adresszuordnung verwenden, während andere die neue statische Blockzuordnung 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 des Add-Ons für HTTP-Anwendungsrouting in Azure Kubernetes Service (AKS)