Skip to content
EOL Watch
Search itemsOpen menu

AzureEnd of support

Azure Kubernetes Service: Kubernetes 1.32 LTS end of life

LTS end of life date for Kubernetes 1.32 on Azure Kubernetes Service: Mar 2027. For clusters with long-term support enabled, support for the version continues only until that date. After it, those clusters must move to the next supported LTS version.

Support ends approx., Mar 2027

· The vendor gives a month, not a day.

ShareAdd to calendarReport an error

What breaks

After the LTS end of life date, long-term support for Kubernetes 1.32 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.

Who is affected

Affected versions

  • 1.32

Matching resource types

  • microsoft.containerservice/managedclusters
  • azurerm_kubernetes_cluster

Fields the check reads

  • k8sversion
  • properties.supportplan
  • kubernetes_version
  • support_plan

Detected by the estate check from

  • Terraform state or plan (JSON)
  • ARM template

Check your estate for this

What to do

  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.

Replacement

Next supported AKS LTS version

Sources

Last checked against the first source in this list on .

Related

Found an error? Report it

The text on this page is drafted with AI assistance from the vendor's text, checked against the official source and approved by a person before it is published. How items are written

Last checked · Added · Changelog for this item