AKS 1.24 Retirement with MADIT's DevOps Experts

Why Version Support Matters in AKS

AKS follows a version support policy where only the latest three minor versions receive patches and security updates. When a version falls out of support, Microsoft stops providing fixes. Running an unsupported version means no security patches, no bug fixes, and eventual forced upgrades on Microsoft's timeline instead of yours.

AKS 1.24 reached end of life, which means clusters still running it need to upgrade. If you've been putting this off, here's how to get it done.

Check Your Current Version

Before anything else, find out what you're running:

AKS only supports upgrading one minor version at a time. If you're on 1.24, you need to go 1.24, 1.25, 1.26, 1.27, and so on. You can't skip versions.

Breaking Changes to Watch For

Every Kubernetes minor version removes deprecated APIs. The biggest pain points when upgrading from 1.24:

Removed APIs: Several beta APIs were removed in 1.25. If your manifests use policy/v1beta1 for PodDisruptionBudgets or batch/v1beta1 for CronJobs, update them to their v1 equivalents.
PSP removal: PodSecurityPolicy was removed in 1.25. If you relied on PSPs, migrate to Pod Security Admission before upgrading.
CSI migration: In-tree storage plugins are being replaced by CSI drivers. Verify your persistent volumes work with the CSI driver for your storage class.

The Upgrade Process

Upgrade the control plane first, then the node pools:

For production clusters, upgrade node pools one at a time and validate workloads between each. AKS performs rolling upgrades by default, cordoning and draining nodes before replacing them.

Node Pool Strategy

If you run multiple node pools (system and user pools), upgrade the system pool first. A few tips:

Set max-surge to control how many extra nodes AKS provisions during the upgrade. Higher values mean faster upgrades but more temporary cost.
Use PodDisruptionBudgets on your workloads so the drain process respects your availability requirements.
Test the upgrade on a dev/staging cluster first. Always.

Keep Up Going Forward

After catching up, stay current by upgrading within a few weeks of each new AKS version release. Consider enabling auto-upgrade for non-production clusters:

Available channels: patch (safest), stable, rapid, and node-image. For production, patch keeps you on the same minor version with the latest patches.

If you need help planning your AKS upgrade path or want a second pair of eyes on your cluster configuration, our consultants at MADIT can help. Contact us to get started.