Es ist wieder so weit. Eine E-Mail von Microsoft landet im Posteingang und kündigt das Support-Ende (EoL) für eine Kubernetes-Version an. Theoretisch ein Routine-Job. Praktisch kann so ein Upgrade aber schnell zur Geduldsprobe werden, wenn lokale CLI-Versionen, Caching-Probleme oder Berechtigungen scheitern. Diese SOP definiert einen fehlerresistenten Prozess.
AKS Version 1.32 wird am 31. März 2026 retired. Danach erfolgt nur noch Platform Support (kein Kubernetes-spezifischer Support mehr).
Ihre Optionen:
1. Upgrade auf 1.33+ (empfohlen, kostenlos) – folgen Sie dieser SOP.
2. Long-Term Support (LTS) für 1.32 kaufen (1 Jahr Verlängerung, kostenpflichtig, nicht alle Add-ons unterstützt).
Platform Support bedeutet: Microsoft hilft nur bei Azure-Infrastrukturproblemen, nicht bei Kubernetes-Bugs oder API-Fragen.
01. Architektur-Basics: Was ist AKS und warum sind Upgrades kritisch?
Der Azure Kubernetes Service (AKS) ist ein Managed Service von Microsoft für das Ausführen von Container-Anwendungen. Die Architektur teilt sich in zwei Bereiche:
- Control Plane (Das Gehirn): Wird von Microsoft verwaltet. Hier laufen die API-Server und die Planungslogik.
- Worker Nodes (Die Muskeln): Werden vom Kunden bezahlt und ausgeführt. Hier laufen die eigentlichen Applikationen (Pods).
Die Open-Source-Community von Kubernetes veröffentlicht sehr schnell neue Versionen. Alte Versionen erreichen nach ca. 12 Monaten ihr End-of-Life. Ignoriert man die Warnungen (z.B. für Version 1.32 bis 31. März 2026), führt Azure irgendwann ein Auto-Upgrade durch. Das birgt massive Risiken, da veraltete APIs (die von den Entwicklern noch genutzt werden) in neuen Versionen plötzlich entfernt sein können. Ein geplantes, kontrolliertes Upgrade ist daher zwingend erforderlich.
02. Das Problem: Warum die Microsoft-Anleitung scheitert
Die offizielle Microsoft-Dokumentation zum AKS-Upgrade zeigt Befehle für die lokale Azure CLI. In Enterprise-Umgebungen führt dieser Ansatz jedoch regelmäßig zu Fehlern:
- Falscher Tenant-Kontext: In Multi-Tenant-Umgebungen landen Befehle im falschen Subscription/Directory.
- Inkonsistente CLI-Versionen: Unterschiedliche Azure CLI-Versionen auf den Workstations der Admins führen zu unterschiedlichem Verhalten.
- Abgelaufene Tokens: PRTs (Primary Refresh Tokens) laufen während langlaufender Upgrades ab – vor allem problematisch bei MFA.
- Silent Failures: Timeouts und Caching-Probleme bleiben unbemerkt bis der Befehl scheinbar "hängt".
Diese SOP nutzt stattdessen die ressourcenspezifische Cloud Shell – sie injiziert automatisch den korrekten Kontext und eliminiert alle lokalen Variablen.
03. Schritt 1: Cloud Shell Execution Environment starten
Um diese Fehlerquellen architektonisch auszuschließen, wird das Upgrade zwingend über die ressourcenspezifische Cloud Shell ausgeführt. Im Gegensatz zur lokalen CLI injiziert die Cloud Shell automatisch den korrekten Subscription-Context und nutzt standardisierte, von Microsoft gewartete Tooling-Versionen.
1. Suchen Sie im Azure Portal nach Kubernetes services.
2. Wählen Sie den Ziel-Cluster (z.B.
prod-cluster-01).3. Klicken Sie oben im Menü auf Connect > Open Cloud Shell.
4. Falls ein Dialog "Switch to Bash in Cloud Shell" erscheint, bestätigen Sie diesen mit Confirm.
04. Schritt 2: Pre-Flight Check (Target Version validieren)
Ermitteln Sie die unterstützten Zielversionen. Azure erzwingt einen sequenziellen Upgrade-Pfad. Sie können Minor-Versionen in der Regel nicht überspringen. Passen Sie die Werte für --resource-group und --name an Ihre Umgebung an. Führen Sie folgenden Befehl in der geöffneten Bash-Session aus:
# Abfrage der verfügbaren Upgrade-Pfade
az aks get-upgrades \
--resource-group RG-Production \
--name prod-cluster-01 \
--output table
05. Schritt 3: Upgrade Execution
Starte das Upgrade mit dem folgenden Befehl. Ersetzen Sie die Versionsnummer durch Ihre Auswahl aus dem vorherigen Schritt. Der Parameter --yes erspart die manuelle Bestätigung.
# Trigger Cluster Upgrade (Control Plane + Node Pools)
az aks upgrade \
--resource-group RG-Production \
--name prod-cluster-01 \
--kubernetes-version 1.33.0 \
--yesAzure erzwingt Minor-Version-Upgrades nur schrittweise (N → N+1). Befindet sich Ihr Cluster noch auf 1.31 oder älter, müssen Sie in zwei separaten Durchläufen aktualisieren: erst auf 1.32, dann auf 1.33. Planen Sie entsprechende Maintenance Windows ein.
06. Schritt 4: Erfolgskontrolle
Nachdem der Befehl durchgelaufen ist, willst du sichergehen, dass alles geklappt hat. Ein einfacher Befehl gibt dir sofort Gewissheit:
# Verifikation der angewendeten Kubernetes-Version
az aks show \
--resource-group RG-Production \
--name prod-cluster-01 \
--query "kubernetesVersion" \
--output tsv
Fazit
Ein solider, wiederholbarer Prozess ist Gold wert. Er spart nicht nur Nerven, sondern vor allem Zeit – Zeit, die wir für spannendere Aufgaben nutzen können. Genau das ist die Art von pragmatischen Enterprise-Lösungen, die wir in der IT-Administration brauchen.