Azure Kubernetes Service: Kubernetes 1.31 LTS end of life

After the LTS end of life date, long-term support for Kubernetes 1.31 ends. LTS-enabled clusters must then be upgraded to the next supported LTS version.

• If a cluster is not upgraded, AKS upgrades it to the next supported LTS version through a platform-initiated upgrade. The cluster is not dropped to a community-supported version.
• The LTS page places this after the 60-day grace period that follows the LTS end of life date. For the initial rollout, the grace period is the window through May 31, 2027, and no platform-initiated upgrade starts before June 1, 2027. After the initial rollout, every end-of-support event has a 60-day grace period before platform-initiated upgrades begin.
• Platform-initiated upgrades apply to AKS in the Azure public cloud; availability in Azure Government and Azure operated by 21Vianet is announced separately.
• A platform-initiated upgrade does not follow the maintenance window, does not stop for deprecated API usage and can override a Pod Disruption Budget.
• The platform-initiated upgrade month in the AKS LTS release calendar is a planning estimate, not an exact upgrade date.

1. List the versions AKS offers as upgrade targets with az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table.
2. Test the workloads against deprecated APIs and other breaking changes between the current and target versions.
3. Upgrade to an offered higher LTS version with az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <lts-kubernetes-version>. An LTS cluster can skip minor versions when the upgrade satisfies version-skew requirements and validation checks. See Long-term support for AKS versions.
4. If the cluster is already past its LTS end of life date, skipping minor versions is conditional: the target must be listed by AKS and satisfy validation checks. AKS allows this upgrade but treats it as an unsupported recovery path.
5. If no target is available for an unsupported cluster, create a new cluster with a supported version and migrate the workloads.
6. To leave LTS instead, move the cluster to the Free or Standard tier and select the KubernetesOfficial support plan. This is possible while the cluster's Kubernetes version is still in community support. After that version exits community support, first upgrade the cluster to a community-supported version.