Long-term support

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 innovation delivered with this release cadence provides huge benefits to you, it challenges you to keep up to date with Kubernetes releases, which can be made more difficult based on the number of AKS clusters you have to maintain.

AKS support types

After approximately one year, the Kubernetes version exits Community support and your AKS clusters are now at risk as bug fixes and security updates become unavailable.

AKS provides one year Community support and one year of long-term support (LTS) to back port security fixes from the community upstream in our public repository. Our upstream LTS working group contributes efforts back to the community to provide our 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 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 and disabling long-term support is a combination of moving your cluster to the Premium tier and explicitly selecting the LTS support plan.

Note

While it's possible to enable LTS when the cluster is in Community support, you'll be charged once you enable the Premium tier.

Create a cluster with LTS enabled

az aks create --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport --kubernetes-version 1.27

Note

Enabling and disabling LTS is a combination of moving your cluster to the Premium tier, as well as enabling long-term support. Both must either be turned on or off.

Enable LTS on an existing cluster

az aks update --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport

Disable LTS on an existing cluster

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

Long term support, 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 may not support Kubernetes versions outside these upstream Community support windows.

See the following table for a list of add-ons and features that aren't supported and the reason why.

Add-on / Feature	Reason it's unsupported
Istio	The Istio support cycle is short (six months), and there will not 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
Cillium	Requires Cillium Enterprise agreement past Community support
Azure Linux	Support timeframe for Azure Linux 2 ends during this LTS cycle
Key Management Service (KMS)	KMSv2 replaces KMS during this LTS cycle
Dapr	AKS extensions are not supported
Application Gateway Ingress Controller	Migration to App Gateway for Containers happens during LTS period
Open Service Mesh	OSM will be 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.
Whilst these AKS managed add-ons aren't supported by Microsoft, you're able to install the Open Source versions of these on your cluster if you wish to use it past Community support.

How we decide the next LTS version

Versions of Kubernetes LTS are available for two years from General Availability, we mark a later version of Kubernetes as LTS based on the following criteria:

• Sufficient time for customers to migrate from the prior LTS version to the current have passed
• 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.

Migrate from LTS to Community support

Using LTS is a way to extend your window to plan a Kubernetes version upgrade. You may want to migrate to a version of Kubernetes that is within the standard support window.

To move from an LTS enabled cluster to a version of Kubernetes that is within the standard support window, you need to disable LTS on the cluster:

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

And then upgrade the cluster to a later supported version:

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.28.3

Note

Kubernetes 1.28.3 is used as an example here, please check the AKS release tracker for available Kubernetes releases.

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.

Migrate from LTS to the next LTS release

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.

For customers that wish 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.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.32.2

Note

Kubernetes version 1.32 is the next Long Term Support Version after 1.27. Customers will get a minimum 6 months of overlap between 1.27 LTS and 1.32 LTS versions to plan upgrades.
Kubernetes 1.32.2 is used as an example version in this article. Check the AKS release tracker for available Kubernetes releases.