Azure Kubernetes Service: Kubernetes 1.37 platform-initiated upgrade

From June 1, 2027, AKS automatically upgrades any cluster that stays on an unsupported Kubernetes version after its 60-day platform support grace period ends. It applies to AKS in the Azure public cloud. Upgrades can occur during or after the listed month. Clusters enrolled in long-term support (LTS) follow the month in the LTS versions table. A platform-initiated upgrade:

• does not follow the maintenance window
• does not stop for deprecated API usage
• can override a Pod Disruption Budget if a node drain times out or fails
• cannot be canceled once started, and cannot be rolled back
• moves the cluster to the lowest supported version within its current support tier

1. Find clusters that are out of support or approaching end of life with the Azure Resource Graph query and the release calendar.
2. Remove dependencies on deprecated APIs: update workloads, manifests, clients, controllers and self-managed add-ons that use APIs removed from the target Kubernetes version.
3. Check the Kubernetes version compatibility of each self-managed add-on, and upgrade or replace an incompatible add-on.
4. Review VM family quota, regional SKU availability, and subnet IP capacity, and test that Pod Disruption Budgets allow a node drain to complete.
5. Upgrade the cluster to a supported version on your own schedule, before the platform-initiated upgrade month. See Upgrade an AKS cluster control plane.
6. If a specific minor version must stay supported for longer, evaluate AKS long-term support, an opt-in that requires the Premium tier. LTS clusters get a platform-initiated upgrade after the LTS end-of-life date and its 60-day grace period.