Freigeben über

Upgradeoptionen und Empfehlungen für Azure Kubernetes Service (AKS)-Cluster

Dieser Artikel behandelt Upgradeoptionen für AKS-Cluster und bietet szenariobasierte Empfehlungen für häufige Upgrade-Herausforderungen.

Upgrade-Optionen

Durchführen manueller Upgrades

Mit manuellen Upgrades können Sie steuern, wann Ihr Cluster auf eine neue Kubernetes-Version aktualisiert wird. Nützlich für Tests oder für die Zielbestimmung einer bestimmten Version.

Konfigurieren automatischer Upgrades

Automatische Upgrades halten Ihren Cluster auf einer unterstützten Version und auf dem neuesten Stand. Dies ist der Fall, wenn Sie festlegen und vergessen möchten.

Besondere Überlegungen für Knotenpools, die mehrere Verfügbarkeitszonen umfassen

AKS wendet in Knotengruppen den bestmöglichen Zonenausgleich an. Während eines Upgrade-Anstiegs sind die Zonen für Überspannungsknoten in Skalierungssätzen virtueller Computer im Voraus unbekannt, was vorübergehend zu einer unausgewogenen Zonenkonfiguration führen kann. AKS löscht Surgeknoten nach dem Upgrade und stellt die ursprüngliche Zonenverteilung wieder her. Wenn Zonen ausgeglichen bleiben sollen, legen Sie den Stoß auf ein Vielfaches von drei Knoten fest.To keep zones balanced, set surge to a multiple of three nodes. PVCs, die Azure LRS-Datenträger verwenden, sind zonengebunden und können Downtime verursachen, wenn sich Surgeknoten in einer anderen Zone befinden. Verwenden Sie ein Pod-Unterbrechungsbudget, um während des Ausgleichs eine hohe Verfügbarkeit aufrechtzuerhalten.

Optimieren von Upgrades zur Verbesserung der Leistung und Minimierung von Unterbrechungen

Kombinieren Sie das Fenster für die geplante Wartung, den maximalen Anstieg, das Pod-Unterbrechungsbudget, das Timeout für den Knotenausgleich und das Timeout für den Knotendurchlauf, um die Wahrscheinlichkeit für erfolgreiche Upgrades mit minimalen Unterbrechungen zu erhöhen.

  • Geplantes Wartungsfenster: Planen Sie das automatische Upgrade während verkehrsärmerer Zeiten (empfehlen mindestens vier Stunden)
  • Max Surge: Höhere Werte beschleunigen Upgrades, können jedoch Workloads stören; 33% wird für die Produktion empfohlen
  • Max Nicht verfügbar: Verwendung, wenn die Kapazität begrenzt ist
  • Pod-Unterbrechungsbudget: Legen Sie dies fest, um die Anzahl ausgefallener Pods während Upgrades zu begrenzen. Überprüfen Sie dies für Ihren Dienst.
  • Timeout für den Knotenausgleich: Konfigurieren Sie die Wartezeit bis zum Entfernen von Pods (der Standardwert beträgt 30 Minuten).
  • Node-Pufferzeit: Upgrade gestaffelt durchführen, um Ausfallzeiten zu minimieren (Standardzeit 0 Minuten)
Upgradeeinstellungen Wie zusätzliche Knoten verwendet werden Erwartetes Verhalten
maxSurge=5, maxUnavailable=0 5 Surgeknoten 5 Surgeknoten für Upgrade
maxSurge=5, maxUnavailable=0 0–4 Surgeknoten Upgrade schlägt aufgrund unzureichender Surgeknoten fehl
maxSurge=0, maxUnavailable=5 Nicht verfügbar 5 vorhandene Knoten für das Upgrade ausgeglichen

Hinweis

Überprüfen Sie vor der Aktualisierung, ob es API-Änderungen gibt, die zu Unterbrechungen führen könnten, und lesen Sie die AKS-Versionshinweise , um Unterbrechungen zu vermeiden.

Validierungen, die im Upgradeprozess verwendet werden

AKS führt Vorabupgradeüberprüfungen durch, um die Clusterintegrität sicherzustellen:

  • Breaking Changes bei der API: Erkennt veraltete APIs.
  • Kubernetes-Upgradeversion: Stellt einen gültigen Upgradepfad sicher.
  • PDB-Konfiguration: Sucht nach falsch konfigurierten PDBs (z. B. maxUnavailable=0).
  • Kontingent: Bestätigt ein ausreichendes Kontingent für Surgeknoten.
  • Subnetz: Überprüft ausreichende IP-Adressen.
  • Zertifikate/Dienstprinzipale: Erkennt abgelaufene Anmeldeinformationen.

Diese Prüfungen helfen dabei, Upgradefehler zu minimieren und frühzeitige Einblicke in Probleme zu bieten.

Häufige Upgradeszenarien und Empfehlungen

Szenario 1: Kapazitätsbeschränkungen

Wenn Ihr Cluster durch SKU oder regionale Kapazität begrenzt ist, können Upgrades fehlschlagen, wenn Überspannungsknoten nicht bereitgestellt werden können. Dies ist üblich bei spezialisierten SKUs (z. B. GPU-Knoten) oder in Regionen mit begrenzten Ressourcen. Fehler wie SKUNotAvailable, , AllocationFailedoder OverconstrainedAllocationRequest können auftreten, wenn maxSurge für die verfügbare Kapazität zu hoch festgelegt ist.

Empfehlungen zur Vermeidung oder Lösung von Problemen

  • Verwenden Sie maxUnavailable, um ein Upgrade vorhandener Knoten durchzuführen, anstatt neue Surgeknoten bereitzustellen. Erfahren Sie mehr.
  • Senken Sie maxSurge, um den Bedarf an zusätzlicher Kapazität zu reduzieren. Erfahren Sie mehr.
  • Verwenden Sie für reine Sicherheitsupdates Sicherheitspatch-Reimages, für die keine Surgeknoten erforderlich sind. Erfahren Sie mehr.

Szenario 2: Knotenausgleichsfehler und Pod-Unterbrechungsbudgets

Upgrades erfordern den Knotenausgleich (das Entfernen von Pods). Abflüsse können fehlschlagen, wenn:

  • Das Beenden von Pods dauert lange (lange Hooks beim Herunterfahren oder persistente Verbindungen).
  • Strikte Pod-Unterbrechungsbudgets blockieren das Entfernen von Pods.

Beispielfehlermeldung:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Empfehlungen zur Vermeidung oder Lösung von Problemen

  • Legen Sie maxUnavailable in Pod-Unterbrechungsbudgets fest, damit mindestens ein Pod entfernt werden kann.

  • Erhöhen Sie die Anzahl der Podreplikate, damit das Unterbrechungsbudget das Entfernen tolerieren kann.

  • Verwenden Sie undrainableNodeBehavior, um Upgrades fortzusetzen, auch wenn einige Knoten nicht entwässert werden können.

    • Zeitplan (Standard): Knoten- und Surge-Ersatz kann gelöscht werden, wodurch sich die Kapazität reduziert.
    • Cordon (Empfohlen): Der Knoten ist gesperrt und beschriftet als kubernetes.azure.com/upgrade-status=Quarantined.

      • Beispiel für einen -Befehl:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        Die folgende Beispielausgabe zeigt das aktualisierte Verhalten eines nicht entladbaren Knotens:

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

  • Verlängern Sie das Ausschaltzeitlimit, wenn die Arbeitslasten mehr Zeit benötigen (der Standardwert beträgt 30 Minuten).

  • Testen Sie PDBs im Staging, überwachen Sie Upgradeereignisse und verwenden Sie blaugrüne Bereitstellungen für kritische Workloads. Erfahren Sie mehr.

Überprüfen von nicht ausgleichsfähigen Knoten

  • Die blockierten Knoten sind für Pods ungeplant und mit der Beschriftung "kubernetes.azure.com/upgrade-status: Quarantined" gekennzeichnet.

  • Überprüfen Sie die Bezeichnung aller blockierten Knoten, wenn beim Upgrade ein Knotenausgleichsfehler auftritt:

    kubectl get nodes --show-labels=true

Korrigieren von nicht ausgleichsfähigen Knoten

  1. Entfernen Sie das verantwortliche Pod-Unterbrechungsbudget:

    kubectl delete pdb <pdb-name>

  2. Entfernen Sie die kubernetes.azure.com/upgrade-status: Quarantined Bezeichnung:

    kubectl label nodes <node-name> <label-name>

  3. Löschen Sie optional den blockierten Knoten:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Nachdem Sie diesen Schritt abgeschlossen haben, können Sie den Clusterstatus abgleichen, indem Sie einen Aktualisierungsvorgang ohne die optionalen Felder ausführen, wie hier beschrieben. Alternativ können Sie den Knotenpool auf dieselbe Anzahl von Knoten skalieren wie die Anzahl der aktualisierten Knoten. Diese Aktion stellt sicher, dass der Knotenpool seine beabsichtigte Originalgröße erhält. AKS priorisiert die Entfernung der blockierten Knoten. Mit diesem Befehl wird auch der Clusterbereitstellungsstatus auf Succeeded wiederhergestellt. Im angegebenen Beispiel ist 2 die Gesamtanzahl der aktualisierten Knoten.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Szenario 3: Langsame Upgrades

Upgrades können durch konservative Einstellungen oder Probleme auf Knotenebene verzögert werden, was sich auf ihre Fähigkeit auswirkt, mit Patches und Verbesserungen auf dem neuesten Stand zu bleiben.

Häufige Ursachen für langsame Upgrades sind:

  • Niedrige maxSurge- oder maxUnavailable-Werte (begrenzt Parallelität).
  • Hohe Durchlaufzeiten (lange Wartezeiten zwischen Knotenupgrades).
  • Ausgleichsfehler (siehe Knotenausgleichsfehler).

Empfehlungen zur Vermeidung oder Lösung von Problemen

  • Für die Produktion: maxSurge=33%, maxUnavailable=1.
  • Für Entwicklungs-/Test: maxSurge=50%, maxUnavailable=2.
  • Verwenden Sie den Betriebssystemsicherheitspatch für schnelles, gezieltes Patchen (verhindert vollständiges Neustrukturieren von Knoten).
  • Aktivieren Sie undrainableNodeBehavior, um Upgrade-Blocker zu vermeiden.

Szenario 4: IP-Erschöpfung

Surgeknoten erfordern zusätzliche IPs. Wenn sich das Subnetz in der Nähe seiner Kapazität befindet, kann die Knotenbereitstellung fehlschlagen (z. B. Error: SubnetIsFull). Dies ist üblich für Azure CNI, hohe maxPodsoder große Knotenanzahlen.

Empfehlungen zur Vermeidung oder Lösung von Problemen

  • Stellen Sie sicher, dass Ihr Subnetz über genügend IPs für alle Knoten, Überspannungsknoten und Pods verfügt:

    • Formel: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • Geben Sie nicht verwendete IPs zurück, oder erweitern Sie das Subnetz (z. B. von /24 auf /22).

  • Verringern Sie den Wert von maxSurge, wenn eine Subnetzerweiterung nicht möglich ist:

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Überwachen der IP-Nutzung mit Azure Monitor oder benutzerdefinierten Warnungen.

  • Reduzieren Sie den Wert von maxPods pro Knoten, bereinigen Sie verwaiste Lastenausgleichs-IPs, und planen Sie die Subnetzgröße für hochskalierte Cluster.

Nächste Schritte

  • Lesen Sie AKS-Patch- und Upgradeanleitungen für bewährte Methoden und Planungstipps, bevor Sie ein Upgrade starten.
  • Überprüfen Sie immer, ob es Breaking Changes für APIs gibt, und validieren Sie die Kompatibilität Ihrer Workloads mit der Kubernetes-Zielversion.
  • Testen Sie Upgradeeinstellungen (z. B. maxSurge, maxUnavailable und PDBs) in einer Staging-Umgebung, um das Produktionsrisiko zu minimieren.
  • Überwachen Sie Upgrade-Ereignisse und die Cluster-Gesundheit während des gesamten Prozesses.