// CLOUD_OPERATIONS

AKS Cluster Upgrade:
Support Ending.

Step-by-step SOP for deterministic Kubernetes updates. Avoid forced auto-upgrades through Cloud Shell execution.

Përparim Kastrati - Author
Përparim Kastrati
2 March 2026 • 7 min read
AKS Version 1.32 End-of-Support: Upgrade to 1.33+ by March 31, 2026

It's that time again. An email from Microsoft arrives in the inbox announcing the end-of-support (EoL) for a Kubernetes version. Theoretically a routine job. In practice, such an upgrade can quickly become a test of patience when local CLI versions, caching issues, or permissions fail. This SOP defines an error-resistant process.

📅
Current EOL Date: March 31, 2026
AKS Version 1.32 will be retired on March 31, 2026. After that, only Platform Support remains (no Kubernetes-specific support).

Your Options:
1. Upgrade to 1.33+ (recommended, free) – follow this SOP.
2. Long-Term Support (LTS) for 1.32 (1 year extension, paid, not all add-ons supported).

Platform Support means: Microsoft helps only with Azure infrastructure issues, not with Kubernetes bugs or API questions.

Context: Why AKS Upgrades Fail

The Azure Kubernetes Service (AKS) is a managed service for container applications. The official Microsoft documentation shows commands for the local Azure CLI – in enterprise environments, this regularly leads to errors:

  • Wrong Tenant Context: In multi-tenant environments, commands land in the wrong subscription/directory.
  • Inconsistent CLI Versions: Different Azure CLI versions lead to different behavior.
  • Expired Tokens: PRTs expire during long-running upgrades – especially problematic with MFA.
  • Silent Failures: Timeouts remain unnoticed until the command appears to "hang".

The solution: Cloud Shell – it automatically injects the correct context and eliminates local variables.

Step 1: Cloud Shell & Subscription Check

⚙️
Cloud Shell Initialization:
1. In Azure Portal: Kubernetes services → Select cluster.
2. Click Connect > Open Cloud Shell.
3. Confirm "Switch to Bash in Cloud Shell" with Confirm.
Azure Portal AKS Connect Button and Cloud Shell
Initial connection via Azure Portal

Subscription Check (The Most Important Anchor)

Critical: Before every AKS upgrade, you must ensure you're working in the correct Azure subscription. As an admin with multiple tenants, a context error inevitably leads to errors.

Azure CLI - Subscription Check 
# 1. List all subscriptions & find ID
az account list --output table

# 2. Explicitly set context
az account set --subscription "b9472c21-d656-411b-91db-607d37b5776b"

# 3. Validation: Which name is now active?
az account show --query name -o tsv
⚠️
Typical Error:
Cloud Shell often starts in the wrong subscription. Without az account set, you'll get "Resource group not found" or accidentally work in the wrong tenant.

Step 2: Set Variables & Pre-Flight Check

Use variables to exclude typos in subsequent commands. This is the safest method for public SOPs.

Azure CLI - Variables & Pre-Flight 
# Set variables (adjust values!)
export RG="_1Password_SCIM"
export CLUSTER="op-scim"

# Check available versions
az aks get-upgrades -g $RG -n $CLUSTER -o table
Azure CLI output of available Kubernetes upgrade versions
The output shows the current status and possible target versions.
📋
Sequential Upgrades: Azure enforces minor version upgrades only step-by-step (N → N+1). You cannot jump directly from 1.30 to 1.32. Plan for two separate runs if necessary.

Step 3: The Controlled Cluster Upgrade

Start the upgrade. The --yes parameter eliminates manual confirmation.

⚠️
Downtime Risk & Duration: The upgrade updates the control plane and performs a "Cordon & Drain" of worker nodes. Plan for 15-30 minutes.
Azure CLI - Upgrade Execution 
# Execute upgrade (adjust version!)
az aks upgrade -g $RG -n $CLUSTER --kubernetes-version 1.33.6 --yes

# Monitor status (runs in background)
az aks wait -g $RG -n $CLUSTER --updated --interval 60
💡
Pro Tip: Node Image Only
For security fixes without K8s version change: az aks upgrade -g $RG -n $CLUSTER --node-image-only --yes – faster and less risky.

Conclusion: Verification & Pro-Tips

Verify the successful upgrade:

Azure CLI - Verification 
# Verification of applied Kubernetes version
az aks show -g $RG -n $CLUSTER --query "kubernetesVersion" -o tsv
Successful output of updated Kubernetes version in Cloud Shell
The version number alone confirms successful upgrade.

Summary

A solid, repeatable process is worth its weight in gold. It saves not only nerves but above all time – time we can use for more exciting tasks. This is exactly the kind of pragmatic enterprise solutions we need in IT administration.

Need assistance with your AKS upgrade?

Request Cloud Operations Sprint
Back to Engineering Log