Ändern der Größe von Knotenpools in Azure Kubernetes Service (AKS)

Möglicherweise möchten Sie die Größe Ihrer virtuellen Computer (VMs) ändern, um eine steigende Anzahl von Bereitstellungen zu berücksichtigen oder eine größere Workload auszuführen. Das direkte Ändern der Größe von AKS-Instanzen wird bei Verwendung von Skalierungssätzen für virtuelle Computer in AKS nicht unterstützt, wie in den Supportrichtlinien für AKS beschrieben:

AKS-Agentknoten werden im Azure Portal als reguläre Azure IaaS-Ressourcen angezeigt. Diese virtuellen Computer werden jedoch in einer benutzerdefinierten Azure-Ressourcengruppe bereitgestellt (in der Regel mit dem Präfix MC_*). Sie können diese Knoten nicht direkt anpassen, indem Sie die IaaS-APIs oder -Ressourcen verwenden. Alle benutzerdefinierten Änderungen, die nicht über die AKS-API durchgeführt werden, werden nicht über ein Upgrade, eine Skalierung, ein Update oder einen Neustart beibehalten.

In diesem Artikel lernen Sie die empfohlene Methode zum Ändern der Größe eines Knotenpools kennen, indem Sie einen neuen Knotenpool mit der gewünschten SKU-Größe erstellen, die vorhandenen Knoten abkabeln und entwässern und dann den vorhandenen Knotenpool entfernen.

Größenänderung eines VMSS-Knotenpools direkt am Ort (Vorschau)

Sie können jetzt die VM-Größe (SKU) eines vorhandenen, VMSS-basierten Knotenpools mit az aks nodepool update --node-vm-size <new-size> in einem einzigen Befehl ändern. Wenn Sie dieses Update auslösen, führt der AKS-Ressourcenanbieter ein rollierendes Upgrade durch:

1. Hochskalieren neuer Knoten auf die Ziel-VM-Größe.
2. Sperren und Leeren der alten Knoten.
3. Löschen der alten Knoten.

Dadurch wird der manuelle Workflow zum Erstellen/Cordon/Drain/Löschen vermieden, der im weiteren Verlauf dieses Artikels beschrieben wird.

So funktioniert der Rollout für die Größenänderung

Das Rollout zur Größenänderung verwendet denselben Rolling-Upgrade-Mechanismus wie ein Node-Image-Upgrade und ein Kubernetes-Versionsupgrade, sodass die folgenden upgradebezogenen Einstellungen berücksichtigt werden, die im Knotenpool bereits konfiguriert sind. Insbesondere berücksichtigt die Größenänderung Folgendes:

• Max. Auftrieb (--max-surge): Steuert, wie viele zusätzliche Knoten mit der Ziel-VM-Größe während des Rollouts hinzugefügt werden. Ein höherer Wert ändert die Größe des Pools schneller, verbraucht jedoch mehr Compute- und IP-Kontingent; ein niedrigerer Wert ist langsamer, aber weniger störend. Der AKS-Standardwert ist 1und 33% wird für Produktionsknotenpools empfohlen.
• Entleerungs-Timeout für Knoten (--drain-timeout): Wie lange AKS auf jedem alten Knoten auf die Auslagerung von Pods wartet, bevor dieser zwangsweise gelöscht wird. Der Standardwert beträgt 30 Minuten. Kombinieren Sie dies mit geeigneten PodDisruptionBudgets, damit Workloads sicher entleert werden können.
• Dauer der Knotenstabilisierungsphase (--node-soak-duration): Wie lange AKS wartet, nachdem ein neuer Knoten den Status „Ready“ erreicht hat, bevor mit dem nächsten Batch fortgefahren wird. Nützlich für die Stabilisierung von Workloads auf der neuen VM-Größe vor dem Fortsetzen des Rollouts.

Da die Größenänderung dieselbe Upgradepipeline verwendet, gelten dieselben Voraussetzungen: Stellen Sie sicher, dass Ihr Abonnement über genügend Ersatzkapazität für die Ziel-VM-Größe und über verfügbare Subnetz-IPs für Surge-Knoten verfügt und dass Ihre PodDisruptionBudgets zulassen, dass jeweils mindestens ein Replikat verdrängt wird, andernfalls kann die Größenänderung beim Draining blockiert werden. Ausführliche Empfehlungen finden Sie unter Bewährte Methoden für AKS-Knotenpoolupgrades.

Voraussetzungen

• AKS-API-Version 2026-01-02-preview oder höher.
• Die neueste Version der Azure CLI-Erweiterung "aks-preview".

Ändern der Größe des Knotenpools

Verwenden Sie den az aks nodepool update Befehl mit dem --node-vm-size Parameter, um die VM-Größe eines vorhandenen VMSS-basierten Knotenpools zu ändern:

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3

Überprüfung und nicht unterstützte Kombinationen

Der AKS-Ressourcenanbieter überprüft die Größenänderungsanforderung und blockiert inkompatible Vm-Größenänderungen. Die folgenden Änderungen werden als Teil einer direkten VMSS-Größenänderung nicht unterstützt :

• Ändern des Typs des Datenträgercontrollers (z. B. von SCSI zu NVMe).
• Ändern der CPU-Architektur (z. B. x64 auf ARM64).
• Ändern der Unterstützung für Confidential Computing (z. B. Aktivieren oder Deaktivieren von SNP).
• Ändern der Hypervisorgenerierung (z. B. V1 zu V2).
• Die Kombination der Größenänderung mit einem Upgrade der Kubernetes-Version oder einer Änderung der Knotenanzahl im selben Vorgang.

Wenn für die Größe ihrer Ziel-VM eine der oben genannten Änderungen erforderlich ist, verwenden Sie stattdessen den manuellen Cordon-and-Drain-Workflow, der in den folgenden Abschnitten beschrieben wird.

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3 \
    --max-surge 33%

Erstellen eines neuen Knotenpools mit der gewünschten SKU

Absperren der vorhandenen Knoten

Durch das Absperren werden bestimmte Knoten als nicht planbar markiert. Dadurch wird verhindert, dass den Knoten weitere Pods hinzugefügt werden.

1. Rufen Sie die Namen der Knoten ab, die Sie mit dem kubectl get nodes Befehl abschotten möchten.

   kubectl get nodes
   

   Die Ausgabe sollte der folgenden Beispielausgabe ähneln, die die Knoten im vorhandenen Knotenpool nodepool1 anzeigt, die Sie sperren möchten.

   NAME                                STATUS   ROLES   AGE     VERSION
   aks-nodepool1-12345678-vmss000000   Ready    agent   7d21h   v1.21.9
   aks-nodepool1-12345678-vmss000001   Ready    agent   7d21h   v1.21.9
   aks-nodepool1-12345678-vmss000002   Ready    agent   7d21h   v1.21.9
   

2. Sperren Sie die bestehenden Knoten mit dem Befehl kubectl cordon ab, und geben Sie die gewünschten Knoten in einer durch Leerzeichen getrennten Liste an. Beispiel:

   kubectl cordon aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002
   

   Die Ausgabe muss dem folgenden Beispielergebnis ähneln, das zeigt, dass die Knoten gesperrt sind.

   node/aks-nodepool1-12345678-vmss000000 cordoned
   node/aks-nodepool1-12345678-vmss000001 cordoned
   node/aks-nodepool1-12345678-vmss000002 cordoned
   

Entleeren der vorhandenen Knoten

Das Entleeren von Knoten führt dazu, dass Pods, die darauf ausgeführt werden, entfernt und auf den anderen, planbaren Knoten neu erstellt werden.

1. Entwässern Sie die vorhandenen Knoten mithilfe des kubectl drain Befehls und der --ignore-daemonsets--delete-emptydir-data Kennzeichnungen, und geben Sie die gewünschten Knoten in einer durch Leerzeichen getrennten Liste an. Beispiel:

   Wichtig

   Die Verwendung von --delete-emptydir-data ist erforderlich, um den von AKS erstellten coredns und die metrics-server-Pods zu entfernen. Wenn Sie dieses Flag nicht verwenden, wird eine Fehlermeldung angezeigt. Weitere Informationen finden Sie in der Dokumentation zu „emptydir“.

   kubectl drain aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002 --ignore-daemonsets --delete-emptydir-data
   

2. Nach Abschluss des Abflussvorgangs sollten alle Pods (mit Ausnahme der Pods, die durch DaemonSets gesteuert werden) im neuen Knotenpool laufen. Sie können dies mithilfe des kubectl get pods-Befehls überprüfen.

   kubectl get pods -o wide -A
   

Problembehebung bei Pod-Entfernungsproblemen

Beim Entwässern von Knoten tritt möglicherweise der folgende Fehler auf:

Error when evicting pods/[podname] -n [namespace] (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

Standardmäßig verfügt Ihr Cluster über von AKS verwaltete Budgets für die Unterbrechung von Pods (z. B. coredns-pdb oder konnectivity-agent) mit einem MinAvailable-Wert von 1. Wenn beispielsweise zwei coredns-Pods ausgeführt werden, kann jeweils nur einer unterbrochen werden. Während einer von ihnen neu erstellt wird und nicht verfügbar ist, kann der andere coredns-Pod aufgrund des Pod-Unterbrechungsbudgets nicht entfernt werden. Dieses Problem löst sich von selbst, wenn der erste coredns-Pod geplant ist und ausgeführt wird, sodass der zweite Pod ordnungsgemäß entfernt und neu erstellt werden kann.

Entfernen des vorhandenen Knotenpools

Nächste Schritte

Nachdem Sie die Größe eines Knotenpools durch Sperren und Entleeren geändert haben, erfahren Sie mehr über die Verwendung mehrerer Knotenpools.