AKS Breaking Changes: What Is Retiring in March 2026 and How to Migrate

March 2026 brought three retirement deadlines to AKS at once. Windows Server 2019, Azure Linux 2.0, and the kubelet certificate rotation tag – three things that, if you haven't migrated yet, you're running out of time. From my audits, I know that at least 40% of enterprise clusters still have at least one node pool on a deprecated OS. Here's a concrete guide on how to fix it.

1. Windows Server 2019 – End of Support from March 1

Microsoft stopped releasing new AKS node images for Windows Server 2019 as of March 1, 2026. This means:

• No security patches – new CVEs will remain unpatched
• Cluster upgrades will fail – new Kubernetes versions don't support WS2019 node pools
• Scaling may stop working – new nodes won't get fresh images

Check if you're affected

# List all node pools running Windows Server 2019
az aks nodepool list \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --query "[?osSku=='Windows2019'].{Name:name, OsSku:osSku, Count:count, VMSize:vmSize}" \
  --output table

If you see Windows2019 in the OsSku column, you need to migrate.

Migrate to Windows Server 2022 (blue-green)

The safest path is to add a new node pool and move workloads:

# 1. Add a new node pool with Windows Server 2022
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name npwin22 \
  --os-type Windows \
  --os-sku Windows2022 \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5
 
# 2. Cordon old pool (prevents scheduling new pods)
kubectl cordon -l agentpool=npwin19
 
# 3. Drain old pool (moves existing workloads)
kubectl drain -l agentpool=npwin19 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=120
 
# 4. Verify all pods are running on the new pool
kubectl get pods -o wide --all-namespaces | grep npwin22
 
# 5. Delete old node pool
az aks nodepool delete \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name npwin19

Tip: If you're considering Windows Server 2025, it's available in preview since March with Containerd 2.0 and Gen2 VMs as defaults. For production, I recommend staying on WS2022 for now – preview means potential breaking changes.

2. Azure Linux 2.0 – End of Support March 31

Azure Linux 2.0 (formerly CBL-Mariner 2.0) reaches end of life on March 31, 2026. After this date:

• No new node images – existing images remain but without patches
• Node pools cannot be scaled – adding new nodes will fail
• Kubernetes upgrades will fail if the target version has no Azure Linux 2.0 image

Check your version

# Check OS SKU and Kubernetes version on all node pools
az aks nodepool list \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --query "[].{Name:name, OsSku:osSku, K8sVersion:currentOrchestratorVersion, OSType:osType}" \
  --output table

If you have AzureLinux with a Kubernetes version below 1.31, you're running Azure Linux 2.0.

Migrate to Azure Linux 3

Good news – migration is essentially a Kubernetes version upgrade:

# 1. Check available versions
az aks get-upgrades \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --output table
 
# 2. Upgrade control plane to 1.31+
az aks upgrade \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --kubernetes-version 1.31.0 \
  --control-plane-only
 
# 3. Upgrade individual node pools
az aks nodepool upgrade \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name systempool \
  --kubernetes-version 1.31.0

Kubernetes 1.31+ automatically uses Azure Linux 3 node images. No blue-green needed – a standard rolling upgrade is sufficient.

What to watch out for

Watch out for custom kernel modules – the new 6.6 kernel may require recompilation. If you use custom DaemonSets with kernel-level drivers (GPU, network accelerators), test on a staging cluster first.

3. Kubelet Certificate Rotation – Tag Retired March 30

The node pool tag aks-disable-kubelet-serving-certificate-rotation=true stops working as of March 30, 2026. If you've been using it to suppress automatic kubelet certificate rotation, you need to remove it:

# Check if you're using the tag
az aks nodepool list \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --query "[].{Name:name, Tags:tags}" \
  --output json | grep -i "certificate-rotation"
 
# Remove the tag from the node pool
az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name systempool \
  --tags "aks-disable-kubelet-serving-certificate-rotation="

After removing the tag, AKS automatically handles kubelet certificate rotation. This is the safer default behavior – manual certificate management was a common source of outages.

Migration Checklist (Summary)

What's Coming Next

March is just the beginning. In the coming months, prepare for:

• Flatcar Container Linux – retirement in June 2026
• Ingress NGINX – end of full support in November 2026, transition to Application Routing add-on
• Ubuntu 24.04 as the default OS from Kubernetes 1.35+

Conclusion

Three retirements in one month isn't common, but it shows how fast the AKS ecosystem is moving forward. The most critical is the Azure Linux 2.0 migration (March 31 is a hard deadline for scaling) and Windows Server 2019 if you run .NET Framework workloads. Don't delay – upgrading a staging cluster takes an hour, production with a blue-green strategy takes an afternoon.

Need help with AKS cluster migration or upgrade strategy planning? Check out our cloud architecture services or reach out for a free consultation.