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

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

Für die meisten Produktionsworkloads ist AKS Automatic die empfohlene Standardclusterumgebung. Es bietet produktionsbereite Standardwerte für Cluster- und Knotenlebenszyklusvorgänge, einschließlich verwaltetem Upgradeverhalten, integrierter Schutzmaßnahmen und reduzierter Betriebsaufwand.

AKS Standard bleibt für Szenarien verfügbar, in denen Sie eine tiefere manuelle Kontrolle über die Upgrademechanik, netzwerkauswahl oder das Verhalten des Knotenpools benötigen.

In diesem Artikel erhalten Sie eine technische Grundlage für AKS-Upgrades, indem Sie Upgradeoptionen, allgemeine Szenarien und Empfehlungen für AKS Automatic und AKS Standard behandeln.

In diesem Artikel wird Folgendes behandelt

Diese technische Referenz umfasst:

• Warum AKS Automatic für die meisten Workloads die empfohlene produktionsbereite Standardeinstellung ist.
• Unterschiede beim Upgradeverhalten zwischen AKS Automatic und AKS Standard.
• Manuelle und automatisierte Upgradepfade im Vergleich – und wann welche Methode verwendet werden sollte.
• Häufige Upgradeszenarien mit bestimmten Empfehlungen.
• Optimierungstechniken für Leistung und minimale Unterbrechungen.
• Überprüfungsprozesse und Überprüfungen vor dem Upgrade.

Für verwandte Anleitungen:

• Informationen zu AKS Automatic (Übersicht) und Standardwerten finden Sie in der Einführung in Azure Kubernetes Service (AKS) Automatisch.
• Ausführliche Informationen zur produktionsorientierten AKS-Upgradestrategie finden Sie unter AKS Produktionsupgradestrategien.
• Informationen zu Upgrade-Mustern für zustandsbehaftete Workloads finden Sie unter Upgrade-Muster für zustandsbehaftete Workloads.
• Eine anleitung für Szenarien finden Sie unter AKS-Upgradeszenarien: Wählen Sie Ihren Pfad aus.
• Wenn Sie mit AKS-Upgrades noch nicht vertraut sind, beginnen Sie mit dem Hub für Upgradeszenarien , um Unterstützung zu erhalten.

Schnelle Navigation

Aktualisieren von Betriebssystemmodellen

AKS Automatic (empfohlene Standardoption für die Produktion)

AKS Automatic ist standardmäßig für den produktionsbereiten Betrieb ausgelegt. Für Upgrades bietet AKS Automatic Folgendes:

• Verwaltete Systemknotenpools.
• Automatisches Clusterupgradeverhalten mit vom Plattform verwalteten Standardwerten.
• Verhalten bei automatischen Upgrades des Knoten-Betriebssystem-Images mit sicherheitsorientiertem Rhythmus.
• Integrierte Überprüfungen auf veraltete Kubernetes-APIs.
• Unterstützung für geplante Wartungszeitpläne.

Verwenden Sie AKS Automatic, wenn Sie die manuelle Upgrade-Orchestrierung minimieren und Produktionscluster mit weniger Aufwand an unterstützte Versionen ausrichten möchten.

AKS Standard (erweitertes Steuerelementmodell)

AKS Standard bietet Ihnen direkte Steuerung über die Abfolge von Upgrades und deren Feinabstimmung. Sie wählen und verwalten Folgendes:

• Manuelle oder automatische Upgradekonfiguration.
• Kanalauswahl aktualisieren.
• Knotenpool und Stoßverhalten.
• Betriebsabläufe rund um Wartungsfenster und Arbeitsauslastungsunterbrechungsbudgets.

Verwenden Sie AKS Standard, wenn Ihre Umgebung Anpassungen erfordert, die über die Automatischen Standardeinstellungen von AKS hinausgehen.

Upgrade-Optionen

Durchführen manueller Upgrades

Gilt in erster Linie für AKS Standard oder für spezialisierte betriebstechnische Workflows.

Mit manuellen Upgrades können Sie steuern, wann Ihr Cluster auf eine neue Kubernetes-Version aktualisiert wird. Diese Upgrades sind nützlich für Tests, mehrstufige Rollouts und gezielte Versionsakzeptanz.

• Aktualisieren eines AKS-Clusters
• Upgrade mehrerer AKS-Cluster über Azure Kubernetes Fleet Manager
• Aktualisieren des Knotenimages
• Anpassen des Upgrades für Knotenanstiege
• Verarbeiten von Updates des Knotenbetriebssystems

Konfigurieren automatischer Upgrades

Bei AKS Standard helfen automatische Upgrades, Cluster auf unterstützten Versionen beizubehalten und gleichzeitig die Kontrolle über Richtlinien und Planung beizubehalten. In AKS Automatic sind Upgradeautomatisierung und Leitplanken bereits Teil des standardmäßigen Betriebsmodells.

• Automatisches Upgraden eines AKS-Clusters
• Automatisches Upgrade mehrerer AKS-Cluster über Azure Kubernetes Fleet Manager
• Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades
• Automatisches Beenden von AKS-Clusterupgrades bei Breaking Changes an der API (Vorschau)
• Automatisches Upgraden von Betriebssystemimages für AKS-Clusterknoten
• Automatisches Anwenden von Sicherheitsupdates auf AKS-Knoten mithilfe von GitHub Actions

Besondere Überlegungen für Knotenpools, die sich über mehrere Verfügbarkeitszonen erstrecken

AKS verwendet in Knotenpools einen Zonenausgleich nach dem Best-Effort-Prinzip. 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. Persistente Volumeansprüche, die lokal redundante Azure-Speicherdatenträger verwenden, sind zonengebunden und können zu Ausfallzeiten führen, wenn sich Überspannungsknoten in einer anderen Zone befinden. Verwenden Sie ein Pod-Unterbrechungsbudget (POD &Unterbrechungs-Budget, PDB), um hohe Verfügbarkeit während der Abflüsse aufrechtzuerhalten.

Optimieren von Upgrades zur Verbesserung der Leistung und Minimierung von Unterbrechungen

Kombinieren Sie geplantes Wartungsfenster, maximale zusätzliche Knotenanzahl, PDB, Zeitlimit für das Leeren des Knotens und Knotenstabilisierungszeit, um die Wahrscheinlichkeit erfolgreicher Upgrades mit minimalen Unterbrechungen zu erhöhen.

AKS Automatik

In AKS Automatic ist das Upgradeverhalten auf Plattformebene vorkonfiguriert. Richten Sie Ihre Optimierung auf die Resilienz der Workloads und die Kapazitätsbereitschaft aus:

• Überprüfen Sie pod-Unterbrechungsbudgets und Replikatanzahlen.
• Stellen Sie das Kontingent und die Subnetzkapazität für das erwartete Wachstum sicher.
• Legen Sie geplante Wartungspläne fest, die auf Zeiträume mit geringem Datenverkehr ausgerichtet sind.
• Upgradeereignisse und die Einsatzbereitschaft kritischer Workloads überwachen.

AKS Standard

In AKS Standard passen Sie die Upgradeoptionen direkt an:

• Geplantes Wartungsfenster: Planen des automatischen Upgrades während weniger Verkehrszeiten. Verwenden Sie es mindestens vier Stunden lang.
• Max. Anstieg: Höhere Werte beschleunigen Upgrades, können aber Workloads stören. Verwenden Sie 33% für die Produktion.
• Max. nicht verfügbar: Verwendung, wenn die Kapazität begrenzt ist.
• Pod-Unterbrechungsbudget: Festgelegt, um die Anzahl der Pods während der Upgrades zu begrenzen. Überprüfen Sie ihren Dienst.
• Timeout für den Knotenablauf: Konfigurieren sie die Wartezeit von Pod-Eviction. Der Standardwert beträgt 30 Minuten.
• Knoten-Einweichzeit: Gestaffelte Upgrades, um Ausfallzeiten zu minimieren. Die Standardeinstellung beträgt 0 Minuten.

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.
• Prüfung auf Ressourcensperren für verwaltete Ressourcen: Prüft, ob auf die Ressourcengruppe des verwalteten Clusters Ressourcensperren angewendet wurden.

Diese Überprüfungen gelten in ganz AKS. In AKS Automatic sind sie in den verwalteten Upgradepfad integriert; in AKS Standard sind sie Teil Ihres betrieblichen Workflows.

Häufige Upgradeszenarien und Empfehlungen

Szenario 1: Kapazitätsbeschränkungen

Wenn Ihr Cluster auf Produktebene oder regionale Kapazität beschränkt ist, können Upgrades fehlschlagen, wenn Überspannungsknoten nicht bereitgestellt werden können. Diese Situation ist üblich für spezielle Produktebenen (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.

AKS Automatische Führung

• Halten Sie geplante Wartungsfenster an Ort und Stelle.
• Überprüfen Sie vor erwarteten Upgrade-Zeiträumen das Abonnementkontingent und die verfügbare Kapazität im Subnetz.
• Halten Sie die Arbeitsauslastungsskalierung und Unterbrechungsbudgets an Wartungsfenstern ausgerichtet.

AKS-Standardanleitung

• Verwenden Sie maxUnavailable das Upgrade mithilfe vorhandener Knoten, anstatt neue Knoten zu übersteigen. Weitere Informationen finden Sie unter Anpassen nicht verfügbarer Knoten während des Upgrades.
• Senken Sie maxSurge, um den Bedarf an zusätzlicher Kapazität zu reduzieren. Weitere Informationen finden Sie unter Anpassen des Knotenanstiegsupgrades.
• Verwenden Sie für reine Sicherheitsupdates Sicherheitspatch-Reimages, für die keine Surgeknoten erforderlich sind. Weitere Informationen finden Sie unter Anwenden von Sicherheits- und Kernelupdates auf Linux-Knoten im Azure Kubernetes-Dienst.

Szenario 2: Knotenausgleichsfehler und Pod-Unterbrechungsbudgets

Upgrades erfordern den Knotenausgleich (das Entfernen von Pods). Abläufe können fehlschlagen, wenn Pods langsam beendet werden oder strenge Pod Disruption Budgets (PDBs) Pod-Räumungen blockieren.

Beispielfehler:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

AKS automatische Führung

• Behandeln Sie PDB- und Replikatstrategie als primäre Zuverlässigkeitskontrollen.
• Überprüfen Sie Unterbrechungsbudgets in der Staging vor dem Produktionsrollout.
• Konfigurieren Sie kritische Workloads so, dass eine rollierende Eviction erfolgreich durchgeführt werden kann.

AKS-Standardleitfaden

Option 1: Erzwingen des Upgrades, Umgehen von PDB-Einschränkungen

Verwenden Sie die Option „Upgrade erzwingen“ nur, wenn PDBs kritische Upgrades verhindern und das Problem nicht behoben werden kann. Diese Aktion setzt die PDB-Schutzmechanismen außer Kraft und kann während des Upgrades möglicherweise zu einer vollständigen Nichtverfügbarkeit des Dienstes führen.

Anforderungen: Azure CLI 2.79.0+ oder AKS-API, Version 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Option 2: Umgang mit nicht drainbaren Knoten unter Einhaltung der PDBs

Verwenden Sie diesen konservativen Ansatz, um PDBs zu berücksichtigen und Upgradefehler zu verhindern.

Verhalten eines nicht drainbaren Knotens konfigurieren:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Verhaltensoptionen:

• Geplant (Standard): Löscht den blockierten Knoten und fährt als Ersatz einen zusätzlichen Knoten hoch.
• Cordon (empfohlen): Cordons Node und beschrifte es als kubernetes.azure.com/upgrade-status=Quarantined.

Maximale Anzahl blockierter Knoten (Vorschau):

• Gibt an, wie viele Knoten, die nicht entwässert werden, toleriert werden
• Muss undrainable-node-behavior eingestellt werden
• Standardmäßig maxSurge Wert (in der Regel 10%), falls nicht angegeben

Voraussetzungen für maximal blockierte Knoten

Die Azure CLI-Erweiterung aks-preview Version 18.0.0b9 oder höher ist erforderlich, um das Feature für maximal blockierte Knoten zu verwenden.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

Beispielkonfiguration mit maximal blockierten Knoten

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

Option 3: Automatische PDB-Verwaltung (Vorschau)

Verwenden Sie die automatische PDB-Verwaltungserweiterung , um PDB-blockierte Entwässerungen proaktiv aufzulösen, ohne PDB-Schutz zu umgehen oder manuelle Bereinigung von isolierten Knoten zu erfordern. Die automatische PDB-Verwaltung erkennt, wenn ein PDB die Verdrängung von Pods auf einem für neue Pods gesperrten Knoten blockiert, und skaliert die Anzahl der Replikate der Bereitstellung vorübergehend hoch, sodass das Disruptions-Budget eingehalten wird. Nach Abschluss des Entleerung skaliert es Replikate auf ihre ursprüngliche Anzahl zurück.

Die automatische PDB-Verwaltung kann auch automatisch PDBs für Bereitstellungen erstellen, die nicht über einen verfügen, um sicherzustellen, dass Ihre Workloads während der Upgradeentleerung geschützt sind. Installations- und Konfigurationsdetails finden Sie unter Automatisches Verwalten von Pod Disruption Budgets während AKS-Upgrades.

Empfehlungen zur Vermeidung von Abflussfehlern

• Setzen Sie maxUnavailable in PDBs, um mindestens eine Pod-Evakuierung zuzulassen
• Pod-Replikate erhöhen, um die Anforderungen des Unterbrechungskontingents zu erfüllen
• Verlängern Sie das Zeitlimit für die Entlastung, wenn Arbeitsauslastungen mehr Zeit benötigen. (Der Standardwert ist 30 Minuten.)
• Verwenden Sie automatische PDB-Verwaltung, um die PDB-Erstellung und die Skalierung von Replikaten während von Drain-Vorgängen zu automatisieren.
• Testen Sie PDBs im Staging, überwachen Sie Upgradeereignisse und verwenden Sie blaugrüne Bereitstellungen für kritische Workloads. Weitere Informationen finden Sie unter Blaugrüne Bereitstellung von AKS-Clustern.

Ü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
  

Auflösen nicht entladbarer 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> kubernetes.azure.com/upgrade-status-
   

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 in az aksder Beschreibung 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

Konservative Einstellungen oder Probleme auf Knotenebene können Upgrades verzögern, 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).

AKS automatische Führung

• Halten Sie Wartungszeitpläne auf dem aktuellen Stand.
• Überwachen Sie den Zustand des Upgradeereignisses und die Workloadbereitschaft.
• Beheben Sie die Blockierung von PDB- oder Kapazitätsproblemen schnell, um längere Verzögerungen zu vermeiden.

AKS-Standardleitfaden

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

Szenario 4: IP-Erschöpfung

Anstiegsknoten erfordern mehr IP-Adressen. Wenn das Subnetz in der Nähe der Kapazität liegt, kann die Knotenbereitstellung fehlschlagen (z. B Error: SubnetIsFull. ). Dieses Szenario wird häufig mit der Azure-Containernetzwerkschnittstelle, hohen maxPods oder großen Knotenanzahlen verwendet.

AKS automatische Führung

• Überprüfen Sie Subnetz- und Kapazitätspläne vor der Produktionserweiterung.
• Überwachen der Netzwerkauslastung als Teil von Routinevorgängen.

Leitfaden zum AKS-Standard

• Stellen Sie sicher, dass Ihr Subnetz über genügend IPs für alle Knoten, Überspannungsknoten und Pods verfügt. Die Formel lautet 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 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.

Häufig gestellte Fragen

Sollte ich AKS Automatic oder AKS Standard für Produktionsupgrades verwenden?

Verwenden Sie für die meisten Produktionsworkloads AKS Automatic. Sie ist als produktionsbereite Standardeinstellung mit verwaltetem Upgrade-Verhalten und integrierten Schutzmechanismen konzipiert.

Verwenden Sie AKS Standard, wenn Sie erweiterte manuelle Kontrolle über Upgradesequenzierung, Infrastrukturoptionen oder Knotenpoolvorgänge benötigen.

Kann ich Open-Source-Tools zur Überprüfung verwenden?

Ja. Viele Open-Source-Tools sind gut in AKS-Upgradeprozesse integriert:

• kube-no-trouble (kubent): Sucht vor Upgrades nach veralteten APIs.
• Trivy: Sicherheitsüberprüfung für Containerimages und Kubernetes-Konfigurationen.
• Sonobuoy: Kubernetes Konformitätstests und Clustervalidierung.
• kube-bench: Sicherheits-Benchmark-Prüfungen gegen Center for Internet Security Standards.
• Polaris: Validierung der bewährten Methoden von Kubernetes.
• kubectl-clean: Bereinigen Sie Kubernetes-Manifeste zur Überprüfung.

Wie kann ich die API-Kompatibilität vor dem Upgrade überprüfen?

Ausführen von Veraltetkeitsprüfungen mithilfe von Tools wie Kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Was unterscheidet AKS-Upgrades von anderen Kubernetes-Plattformen?

AKS bietet mehrere einzigartige Vorteile:

• Verwaltete Betriebspfade in AKS Automatic für einen geringeren Upgradeaufwand.
• Native Azure-Integration in Azure Traffic Manager, Azure Load Balancer und Netzwerk.
• Azure Kubernetes Fleet Manager für koordinierte Multicluster-Upgrades.
• Automatisches Patchen von Knotenimages ohne manuelle Knotenverwaltung.
• Integrierte Überprüfung für Kontingente, Netzwerke und Anmeldeinformationen.
• Azure-Unterstützung für Upgradeprobleme.

Wählen Sie Ihren Upgradepfad

In diesem Artikel erhalten Sie eine technische Grundlage. Wählen Sie nun Ihren szenariobasierten Pfad aus.

Sind Sie bereit für die Ausführung?

Entscheiden Sie sich immer noch?

Verwenden Sie den Hub für Upgradeszenarien für eine geführte Entscheidungsstruktur, die Folgendes berücksichtigt:

• Ausfalltoleranz
• Umgebungskomplexität
• Risikoprofil
• Zeitachseneinschränkungen

Endgültige Empfehlungen

• Verwenden Sie AKS Automatic für die meisten Produktionsworkloads.
• Lesen Sie die Anleitungen zu AKS-Patches und -Upgrades, um bewährte Methoden und Planungstipps zu erhalten, bevor Sie mit einem Upgrade beginnen.
• Ü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.