Supported Kubernetes versions in Azure Kubernetes Service (AKS)

The Kubernetes community releases minor versions roughly every four months.

Minor version releases include new features and improvements. Patch releases are more frequent (sometimes weekly) and are intended for critical bug fixes within a minor version. Patch releases include fixes for security vulnerabilities or major bugs.

Kubernetes versions

Kubernetes uses the standard Semantic Versioning versioning scheme for each version:

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

Each number in the version indicates general compatibility with the previous version:

• Major versions change when incompatible API updates or backwards compatibility might be broken.
• Minor versions change when functionality updates are made that are backwards compatible to the other minor releases.
• Patch versions change when backwards-compatible bug fixes are made.

Aim to run the latest patch release of the minor version you're running. For example, if your production cluster is on 1.29.1 and 1.29.2 is the latest available patch version available for the 1.29 minor version, you should upgrade to 1.29.2 as soon as possible to ensure your cluster is fully patched and supported.

AKS Kubernetes release calendar

View the upcoming version releases on the AKS Kubernetes release calendar. To see real-time updates of region release status and version release notes, visit the AKS release status webpage. To learn more about the release status webpage, see AKS release tracker.

For the past release history, see Kubernetes history.

* Indicates the version is designated for Long Term Support

AKS Kubernetes release schedule Gantt chart

If you prefer to see this information visually, here's a Gantt chart with all the current releases displayed:

AKS components breaking changes by version

Note the following important changes before you upgrade to any of the available minor versions:

Kubernetes 1.30

Kubernetes 1.29

Kubernetes 1.28

Kubernetes 1.27

Alias minor version

AKS allows you to create a cluster without specifying the exact patch version. When you create a cluster without designating a patch, the cluster runs the minor version's latest GA patch. For example, if you create a cluster with 1.29 and 1.29.2 is the latest GA'd patch available, your cluster will be created with 1.29.2. If you want to upgrade your patch version in the same minor version, please use auto-upgrade.

To see what patch you're on, run the az aks show --resource-group myResourceGroup --name myAKSCluster command. The currentKubernetesVersion property shows the whole Kubernetes version.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.chinaeast2.cx.prod.service.azk8s.cn",
  "currentKubernetesVersion": "1.29.2",
}

Kubernetes version support policy

AKS defines a generally available (GA) version as a version available in all regions and enabled in all SLO or SLA measurements. AKS supports three GA minor versions of Kubernetes:

• The latest GA minor version released in AKS (which we refer to as N).
• Two previous minor versions.
  • Each supported minor version can support any number of patches at a given time. AKS reserves the right to deprecate patches if a critical CVE or security vulnerability is detected. For awareness on patch availability and any ad-hoc deprecation, please refer to version release notes and visit the AKS release status webpage.

AKS might also support preview versions, which are explicitly labeled and subject to preview terms and conditions.

AKS provides platform support only for one GA minor version of Kubernetes after the regular supported versions. The platform support window of Kubernetes versions on AKS is known as "N-3". For more information, see platform support policy.

The supported window of Kubernetes minor versions on AKS is known as "N-2", where N refers to the latest release, meaning that two previous minor releases are also supported.

For example, on the day that AKS introduces version 1.29, support is provided for the following versions:

When a new minor version is introduced, the oldest minor version is deprecated and removed. For example, let's say the current supported minor version list is:

1.29
1.28
1.27

When AKS releases 1.30, all the 1.27 versions go out of support 30 days later.

AKS may support any number of patches based on upstream community release availability for a given minor version. AKS reserves the right to deprecate any of these patches at any given time due to a CVE or potential bug concern. You're always encouraged to use the latest patch for a minor version.

Platform support policy

Platform support policy is a reduced support plan for certain unsupported Kubernetes versions. During platform support, customers only receive support from Azure for AKS/Azure platform related issues. Any issues related to Kubernetes functionality and components aren't supported.

Platform support policy applies to clusters in an n-3 version (where n is the latest supported AKS GA minor version), before the cluster drops to n-4. For example, Kubernetes v1.26 is considered platform support when v1.29 is the latest GA version. However, during the v1.30 GA release, v1.26 will then auto-upgrade to v1.27. If you are a running an n-2 version, the moment it becomes n-3 it also becomes deprecated, and you enter into the platform support policy.

AKS relies on the releases and patches from Kubernetes, which is an Open Source project that only supports a sliding window of three minor versions. AKS can only guarantee full support while those versions are being serviced upstream. Since there's no more patches being produced upstream, AKS can either leave those versions unpatched or fork. Due to this limitation, platform support doesn't support anything from relying on Kubernetes upstream.

This table outlines support guidelines for Community Support compared to Platform support.

Supported kubectl versions

You can use one minor version older or newer of kubectl relative to your kube-apiserver version, consistent with the Kubernetes support policy for kubectl.

For example, if your kube-apiserver is at 1.28, then you can use versions 1.27 to 1.29 of kubectl with that kube-apiserver.

To install or update kubectl to the latest version, run:

az aks install-cli

Install-AzAksKubectl -Version latest

Long Term Support (LTS)

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.

For more details on LTS, see Long term support for Azure Kubernetes Service (AKS).

Release and deprecation process

You can reference upcoming version releases and deprecations on the AKS Kubernetes release calendar.

For new minor versions of Kubernetes:

• AKS publishes an announcement with the planned date of a new version release and respective old version deprecation on the AKS Release notes at least 30 days prior to removal.
• AKS uses Azure Advisor to alert you if a new version could cause issues in your cluster because of deprecated APIs. Azure Advisor also alerts you if you're out of support
• AKS publishes a service health notification available to all users with AKS and portal access and sends an email to the subscription administrators with the planned version removal dates.

• You have 30 days from version removal to upgrade to a supported minor version release to continue receiving support.

For new patch versions of Kubernetes:

• Because of the urgent nature of patch versions, they can be introduced into the service as they become available. Once available, patches have a two month minimum lifecycle.
• In general, AKS doesn't broadly communicate the release of new patch versions. However, AKS constantly monitors and validates available CVE patches to support them in AKS in a timely manner. If a critical patch is found or user action is required, AKS notifies you to upgrade to the newly available patch.
• You have 30 days from a patch release's removal from AKS to upgrade into a supported patch and continue receiving support. However, you'll no longer be able to create clusters or node pools once the version is deprecated/removed.

Supported versions policy exceptions

AKS reserves the right to add or remove new/existing versions with one or more critical production-impacting bugs or security issues without advance notice.

Specific patch releases might be skipped or rollout accelerated, depending on the severity of the bug or security issue.

Azure portal and CLI versions

When you deploy an AKS cluster with Azure portal, Azure CLI, Azure PowerShell, the cluster defaults to the N-1 minor version and latest patch. For example, if AKS supports 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, and 1.27.10, the default version selected is 1.28.7.

az aks get-versions --location chinaeast2 --output table

Get-AzAksVersion -Location chinaeast2

FAQ

How does Azure notify me of new Kubernetes versions?

The AKS team publishes announcements with planned dates of the new Kubernetes versions in our documentation, GitHub, and in emails to subscription administrators who own clusters that are going to fall out of support. AKS also uses Azure Advisor to alert you inside the Azure portal if you're out of support and inform you of deprecated APIs that can affect your application or development process.

How often should I expect to upgrade Kubernetes versions to stay in support?

Starting with Kubernetes 1.19, the open source community has expanded support to one year. AKS commits to enabling patches and support matching the upstream commitments. For AKS clusters on 1.19 and greater, you can upgrade at a minimum of once a year to stay on a supported version.

What happens when you upgrade a Kubernetes cluster with a minor version that isn't supported?

If you're on the n-3 version or older, it means you're outside of support and will be asked to upgrade. When your upgrade from version n-3 to n-2 succeeds, you're back within our support policies. For example:

• If the oldest supported AKS minor version is 1.27 and you're on 1.26 or older, you're outside of support.
• When you successfully upgrade from 1.26 to 1.27 or higher, you're back within our support policies.

Downgrades aren't supported.

What does 'Outside of Support' mean?

'Outside of Support' means that:

• The version you're running is outside of the supported versions list.
• You'll be asked to upgrade the cluster to a supported version when requesting support, unless you're within the 30-day grace period after version deprecation.

Additionally, AKS doesn't make any runtime or other guarantees for clusters outside of the supported versions list.

What happens when you scale a Kubernetes cluster with a minor version that isn't supported?

For minor versions not supported by AKS, scaling in or out should continue to work. Since there are no guarantees with quality of service, we recommend upgrading to bring your cluster back into support.

Can you stay on a Kubernetes version forever?

If a cluster has been out of support for more than three (3) minor versions and has been found to carry security risks, Azure proactively contacts you to upgrade your cluster. If you don't take further action, Azure reserves the right to automatically upgrade your cluster on your behalf.

What happens if you scale a Kubernetes cluster with a minor version that isn't supported?

For minor versions not supported by AKS, scaling in or out should continue to work. Since there are no guarantees with quality of service, we recommend upgrading to bring your cluster back into support.

What version does the control plane support if the node pool isn't in one of the supported AKS versions?

The control plane must be within a window of versions from all node pools. For details on upgrading the control plane or node pools, visit documentation on upgrading node pools.

What is the allowed difference in versions between control plane and node pool?

The version skew policy now allows a difference of upto 3 versions between control plane and agent pools. AKS follows this skew version policy change starting from version 1.28 onwards.

Can I skip multiple AKS versions during cluster upgrade?

When you upgrade a supported AKS cluster, Kubernetes minor versions can't be skipped. Kubernetes control planes version skew policy doesn't support minor version skipping. For example, upgrades between:

• 1.28.x -> 1.29.x: allowed.
• 1.27.x -> 1.28.x: allowed.
• 1.27.x -> 1.29.x: not allowed.

Please note that for control plane version upgrades, you can go upto 3 minor versions for community supported versions in sequential fashion.

To upgrade from 1.27.x -> 1.29.x:

1. Upgrade from 1.27.x -> 1.28.x.
2. Upgrade from 1.28.x -> 1.29.x.

Note starting from 1.28 version onwards, agentpool versions can be upto 3 versions older to control plane versions per version skew policy. When your version is much behind the minimum supported version, you may have to do more than one control plane upgrade operation to get to the minimum supported version. For example, if your current control plane version is 1.23.x and you intend to upgrade to a minimum supported version of 1.27.x as an example. You may have to upgrade sequentially 4 times from 1.23.x in order to get to 1.27.x. Also note that Agent pool versions can be upgraded upto the control plane minor version within the limits of version skew policy. This means in the above example you can upgrade agentpool version twice i.e once from 1.23.x to 1.25.x, when the control plane version is at 1.25.x. And subsequently from 1.25.x to 1.27.x , when control plane version is at 1.27.x. When upgrading in-place i.e control plane and agent pool together the same rules applicable to control plane upgrade written above applies.

When performing an upgrade from an unsupported version that skips two or more minor versions, the upgrade is performed without any guarantee of functionality and is excluded from the service-level agreements and limited warranty. Clusters running unsupported version has the flexibility of decoupling control plane upgrades with node pool upgrades. However if your version is significantly out of date, we recommend that you re-create the cluster.

Can I create a new 1.xx.x cluster during the platform support window?

Yes Creation of agent pools and clusters are allowed during Platform Support period.

I'm on a freshly deprecated version that is out of platform support, can I still add new node pools? Or will I have to upgrade?

No. You aren't allowed to add node pools of the deprecated version to your cluster. Creation or upgrade of node pools upto the unsupported version control plane version is allowed, irrespective of version difference between node pool and the control plane. Only alias minor upgrades are allowed.

Next steps

For information on how to upgrade your cluster, see:

• Upgrade an Azure Kubernetes Service (AKS) cluster
• Upgrade multiple AKS clusters via Azure Kubernetes Fleet Manager