Long-term support for Azure Kubernetes Service (AKS) versions

Article
12/02/2024

The Kubernetes community releases a new minor version approximately every four months, with a support window for each version for one year. In Azure Kubernetes Service (AKS), this support window is called community support.

AKS supports versions of Kubernetes that are within this community support window to push bug fixes and security updates from community releases. While the community support release cadence provides benefits, it requires that you keep up to date with Kubernetes releases, which can be difficult depending on your application's dependencies and the pace of change in the Kubernetes ecosystem.

To help you manage your Kubernetes version upgrades, AKS provides a long-term support (LTS) option, which extends the support window for a Kubernetes version to give you more time to plan and test upgrades to newer Kubernetes versions.

AKS support types

After approximately one year, a given Kubernetes minor version exits community support, making bug fixes and security updates unavailable for your AKS clusters.

AKS provides one year of community support and one year of long-term support to back port security fixes from the community upstream in the public AKS repository. The upstream LTS working group contributes efforts back to the community to provide customers with a longer support window. LTS intends to give you an extended period of time to plan and test for upgrades over a two-year period from the general availability (GA) of the designated Kubernetes version.

	Community support	Long-term support
When to use	When you can keep up with upstream Kubernetes releases	When you need control over when to migrate from one version to another
Support versions	Three GA minor versions	One Kubernetes version (currently 1.27) for two years

Enable long-term support

Enabling LTS requires moving your cluster to the Premium tier and explicitly selecting the LTS support plan. While it's possible to enable LTS when the cluster is in *community support, you'll be charged once you enable the Premium tier.

Enable LTS on a new cluster

Create a new cluster with LTS enabled using the az aks create command.

The following command creates a new AKS cluster with LTS enabled using Kubernetes version 1.27 as an example. To review available Kubernetes releases, see the AKS release tracker.
```
az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --generate-ssh-keys
```

Enable LTS on an existing cluster

Enable LTS on an existing cluster using the az aks update command.

az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport

Migrate to the latest LTS version

The upstream Kubernetes community supports a two-minor-version upgrade path. The process migrates the objects in your Kubernetes cluster as part of the upgrade process, and provides a tested and accredited migration path.

If you want to carry out an in-place migration, the AKS service will migrate your control plane from the previous LTS version to the latest, and then migrate your data plane. To carry out an in-place upgrade to the latest LTS version, you need to specify an LTS enabled Kubernetes version as the upgrade target.

Migrate to the latest LTS version using the az aks upgrade command.

The following command uses Kubernetes version 1.32.2 as an example version. To review available Kubernetes releases, see the AKS release tracker.
```
az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.32.2
```
Note

1.30 is the next LTS version after 1.27. You can opt into LTS from a 1.30 version cluster through the steps given above. LTS version 1.27 will go end of life (EOL) by July 2025. Supported Patches in LTS today : [1.27.100] [https://github.com/aks-lts/kubernetes/blob/release-1.27-lts/CHANGELOG/CHANGELOG-1.27.md#v127100-akslts]

Disable long-term support on an existing cluster

Disabling LTS on an existing cluster requires moving your cluster to the free or standard tier and explicitly selecting the KubernetesOfficial support plan.

There are approximately two years between one LTS version and the next. In lieu of upstream support for migrating more than two minor versions, there's a high likelihood your application depends on Kubernetes APIs that have been deprecated. We recommend you thoroughly test your application on the target LTS Kubernetes version and carry out a blue/green deployment from one version to another.

Disable LTS on an existing cluster using the az aks update command.

az aks update --resource-group <resource-group-name> --name <cluster-name> --tier [free|standard] --k8s-support-plan KubernetesOfficial

Upgrade the cluster to a later supported version using the az aks upgrade command.

The following command uses Kubernetes version 1.28.3 as an example version. To review available Kubernetes releases, see the AKS release tracker.
```
az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.28.3
```

Unsupported add-ons and features

The AKS team currently tracks add-on versions where Kubernetes community support exists. Once a version leaves community support, we rely on open-source projects for managed add-ons to continue that support. Due to various external factors, some add-ons and features might not support Kubernetes versions outside these upstream community support windows.

The following table provides a list of add-ons and features that aren't supported and the reasons they're unsupported:

Add-on / Feature	Reason it's unsupported
Istio	The Istio support cycle is short (six months), and there won't be maintenance releases for Kubernetes 1.27.
Keda	Unable to guarantee future version compatibility with Kubernetes 1.27.
Calico	Requires Calico Enterprise agreement past community support.
Key Management Service (KMS)	KMSv2 replaces KMS during this LTS cycle.
Dapr	AKS extensions aren't supported.
Application Gateway Ingress Controller	Migration to App Gateway for Containers happens during LTS period.
Open Service Mesh	OSM is deprecated.
AAD Pod Identity	Deprecated in place of Workload Identity.

Note

You can't move your cluster to long-term support if any of these add-ons or features are enabled.

While these AKS managed add-ons aren't supported by Microsoft, you can install their open-source versions on your cluster if you want to use them past community support.

How we decide the next LTS version

Versions of Kubernetes LTS are available for two years from GA, and we mark a higher version of Kubernetes as LTS based on the following criteria:

Sufficient time has passed for customers to migrate from the prior LTS version to the current LTS version.
The previous version has had a two year support window.

Read the AKS release notes to stay informed of when you're able to plan your migration.

Frequently asked questions

Community support for AKS 1.27 ends expires in July 2024. Can I create a new AKS cluster with version 1.27 after that date?

Yes, as long as LTS is enabled on the cluster, you can create a new AKS cluster with version 1.27 after the community support window has ended.

Can I enable and disable LTS on AKS 1.27 after the end of community support?

You can enable the LTS support plan on AKS 1.27 after the end of community support. However, you can't disable LTS on AKS 1.27 after the end of community support.

I have a cluster running on version 1.27. Does it mean it is automatically in LTS?

No, you need to explicitly enable LTS on the cluster to receive LTS support. Enabling LTS also requires being on the Premium tier.

What is the pricing model for LTS?

LTS is available on the Premium tier, please refer to the Premium tier pricing for more information.

After enabling LTS, my cluster's autoUpgradeChannel has changed to patch channel

This is expected. If there was no defined autoUpgradeChannel for the AKS cluster, it will default to patch with LTS.