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.
Kontext: Warum AKS-Upgrades scheitern
Der Azure Kubernetes Service (AKS) ist ein Managed Service für Container-Anwendungen. Die offizielle Microsoft-Dokumentation zeigt Befehle für die lokale Azure CLI – in Enterprise-Umgebungen führt das regelmäßig zu Fehlern:
- Falscher Tenant-Kontext: In Multi-Tenant-Umgebungen landen Befehle im falschen Subscription/Directory.
- Inkonsistente CLI-Versionen: Unterschiedliche Azure CLI-Versionen führen zu unterschiedlichem Verhalten.
- Abgelaufene Tokens: PRTs laufen während langlaufender Upgrades ab – vor allem problematisch bei MFA.
- Silent Failures: Timeouts bleiben unbemerkt bis der Befehl scheinbar "hängt".
Die Lösung: Cloud Shell – sie injiziert automatisch den korrekten Kontext und eliminiert lokale Variablen.
Schritt 1: Cloud Shell & Subscription-Check
1. Im Azure Portal: Kubernetes services → Cluster wählen.
2. Auf Connect > Open Cloud Shell klicken.
3. "Switch to Bash in Cloud Shell" mit Confirm bestätigen.
Subscription-Check (der wichtigste Anker)
Kritisch: Vor jedem AKS-Upgrade müssen Sie sicherstellen, dass Sie in der richtigen Azure Subscription arbeiten. Als Admin mit mehreren Tenants führt ein Kontext-Fehler unweigerlich zu Fehlern.
# 1. Alle Subscriptions auflisten & ID finden
az account list --output table
# 2. Den Kontext explizit setzen
az account set --subscription "b9472c21-d656-411b-91db-607d37b5776b"
# 3. Validierung: Welcher Name ist jetzt aktiv?
az account show --query name -o tsvDie Cloud Shell startet oft in der falschen Subscription. Ohne
az account set
erhalten Sie "Resource group not found" oder arbeiten versehentlich im falschen Tenant.
Schritt 2: Variablen setzen & Pre-Flight Check
Nutzen Sie Variablen , um Tippfehler in den folgenden Befehlen auszuschließen. Das ist die sicherste Methode für öffentliche SOPs.
# Variablen setzen (Werte anpassen!)
export RG="<IHRE_RG_NAME>_1Password_SCIM"
export CLUSTER="op-scim"
# Verfügbare Versionen prüfen
az aks get-upgrades -g $RG -n $CLUSTER -o table
Azure erzwingt Minor-Version-Upgrades nur schrittweise (N → N+1). Sie können nicht von 1.30 direkt auf 1.32 springen. Planen Sie ggf. zwei separate Durchläufe ein.
Schritt 3: Das kontrollierte Cluster-Upgrade
Starten Sie das Upgrade. Der Parameter
--yes
erspart die manuelle Bestätigung.
# Upgrade ausführen (Version anpassen!)
az aks upgrade -g $RG -n $CLUSTER --kubernetes-version 1.33.6 --yes
# Status überwachen (läuft im Hintergrund weiter)
az aks wait -g $RG -n $CLUSTER --updated --interval 60Für Security-Fixes ohne K8s-Version-Change:
az aks upgrade -g $RG -n $CLUSTER --node-image-only --yes
– schneller und risikoärmer.
Abschluss: Verifikation & Pro-Tipps
Überprüfen Sie das erfolgreiche Upgrade:
# Verifikation der angewendeten Kubernetes-Version
az aks show -g $RG -n $CLUSTER --query "kubernetesVersion" -o 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.
Benötigen Sie Unterstützung bei Ihrem AKS Upgrade?
Cloud Operations Sprint anfragen