AKS Version: What K8s Version Is Supported and How to Upgrade Your Clusters

What Is Azure Kubernetes Service (AKS)? 

Azure Kubernetes Service (AKS) is a fully managed container orchestration service offered by Microsoft. It simplifies Kubernetes management, deployment, and operations. Users can quickly scale, monitor, and secure clusters, focusing more on applications than infrastructure. AKS integrates with Azure DevOps, Active Directory, and other Azure services to provide a complete environment for managing containerized applications.

This is part of a series of articles about Kubernetes versions.

What Kubernetes Versions Are Supported in Azure Kubernetes Service? 

Azure Kubernetes Service (AKS) supports the last three Kubernetes minor versions for which there is a generally available (GA) AKS release. For example, if the current AKS GA version is 1.21, AKS supports 1.21, 1.20, and 1.19. 

The Kubernetes community issues minor versions approximately every three months, and the community support window for each minor version has been extended from nine months to one year starting with version 1.19. AKS typically releases its GA of a Kubernetes minor release within 1-2 months of the upstream release.

AKS provides a release calendar and maintains a support policy that includes 12 months of support for a generally available (GA) Kubernetes version. The AKS Kubernetes release calendar shows upcoming Kubernetes version releases, their AKS preview date, AKS GA date, and expected end of life, allowing users to plan upgrades accordingly.

The image below shows an example of the AKS release cycle. For example, you can see that Kubernetes 1.25, which was released upstream in September 2022, was released in GA (“Live”) on AKS in December 2022, and was supported by AKS until December 2023. After that, AKS provides Platform Support on an “N-3” basis. For some versions, such as version 1.27, AKS provides Long Term Support. These support options are explained in more detail below.

Source: Azure

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better manage and upgrade AKS clusters:

Plan upgrades during low traffic

Schedule upgrades during periods of low traffic to minimize impact on your applications.

Automate upgrade processes

Use automation tools like Azure DevOps to streamline and manage the upgrade process.

Leverage AKS release tracker

Regularly check the AKS release tracker to stay informed about new versions and plan your upgrades accordingly.

Use canary deployments

Implement canary deployments to gradually roll out upgrades and detect issues early.

Backup before upgrading

Ensure you have a full backup of your cluster and its configurations before initiating an upgrade.

Understanding AKS Support Types 

There are three types of support offered by AKS for Kubernetes versions:

Community Support

Community support for Kubernetes versions within AKS is designed to match the upstream Kubernetes community’s support window, extending it to one year from the time of the AKS GA release. This ensures that AKS users have access to bug fixes and security updates directly from the Kubernetes community releases during this period. 

The main advantage of community support is the ability to stay current with the latest Kubernetes innovations, which are delivered approximately every four months. However, this rapid pace of innovation necessitates regular updates to your AKS clusters to keep them within the support window, potentially posing a challenge for organizations managing multiple clusters.

Long-term Support

Long-term support (LTS) in AKS provides an additional layer of stability by offering a two-year support window from the general availability (GA) of a specific Kubernetes version. This extended support includes backporting security fixes from the community to the supported LTS version, which is managed in a public repository by the AKS team and the LTS working group. 

The intention behind LTS is to allow more time for users to plan and test upgrades, making it easier to manage the transition between Kubernetes versions. AKS only provides LTS for certain Kubernetes versions. For example, Kubernetes version 1.27 aws designated as an LTS version.

Platform Support

AKS provides an additional support option called Platform Support, which offers a reduced level of support for certain Kubernetes versions that are no longer fully supported. This policy applies to Kubernetes versions in the “N-3” stage, where “N” represents the latest supported AKS GA minor version.

Under the Platform Support policy, AKS clusters running on an N-3 version receive limited support, until the release of a new GA version. They then automatically upgrade to the N-2 version. This means, for instance, that Kubernetes version 1.25 transitions to Platform Support when version 1.28 becomes the latest GA version. Then, with the release of version 1.29, version 1.25 is longer supported and is automatically upgraded to version 1.26.

Unlike community support, platform support focuses on Azure platform functionality and does not cover Kubernetes components, including add-ons, component updates, hotfixes, bug fixes, security patches, Kubernetes API support, and several other Kubernetes-related functionalities.

What Is the AKS Release Tracker? 

The AKS Release Tracker allows AKS users to track the availability of Kubernetes versions in Azure Kubernetes Service. The tracker shows new AKS releases as they roll out to various regions. When AKS releases its support for a new version of Kubernetes, it gradually rolls out the new release to global Azure regions over a period of approximately 10 business days. 

You can view the AKS release tracker here. 

Quick Tutorial: Upgrading an AKS Cluster 

To manage an AKS cluster, it’s crucial to periodically upgrade it to an up-to-date Kubernetes version. This tutorial shows how to find and implement upgrades to an AKS cluster using the Azure CLI. The code in this tutorial was shared in the official AKS documentation.
When upgrading the AKS cluster, don’t overlook minor Kubernetes versions. Updates must be implemented in order, meaning that you can upgrade from 1.14.x to 1.15.x or from 1.15.x to 1.16.x, but not directly from 1.14.x to 1.16.x. The only exception is if you are upgrading from an unsupported version to a supported version, in which case it is possible to skip versions. If the version is very out of date, it might be better to recreate the cluster altogether.

Finding Available AKS Cluster Upgrades

You can use the az aks get-upgrades command to see which Kubernetes versions are available for an AKS cluster:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

The output should display the current Kubernetes version and list the available releases under

“upgrades”:

{
  "agentPoolProfiles": null,
  "controlPlaneProfile": {
    "kubernetesVersion": "1.26.6",
    ...
    "upgrades": [
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.1"
      },
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.3"
      }
    ]
  },
  ...
}

Troubleshooting an AKS Cluster Upgrade Error Message

In some cases, you may receive an error message telling you that your version of Azure CLI is not compatible with the appservice-kube extension. This could happen if your version is older than the minimum required version (currently 2.34.1). For example, your CLI core version might be 2.0.81 and require an upgrade. You can do this by running az upgrade or reinstalling the Azure CLI (if your version is significantly older).

If the CLI is up-to-date but there are no available upgrades, you will receive a simple error message saying Table output unavailable. In this case, try creating a new AKS cluster using a supported version of Kubernetes and move your workloads to this new cluster. However, AKS won’t support a cluster upgrade to a new Kubernetes version if the az aks get-upgrades command returns an output showing that there are no available upgrades.

Troubleshooting AKS Upgrades with Komodor

AKS upgrades often introduce issues in clusters, which require complex troubleshooting. Without the right tools and expertise in place, the troubleshooting process can become stressful, ineffective and time-consuming. Some best practices can help minimize the chances of things breaking down, but eventually something will go wrong – simply because it can.

This is where Komodor comes in – Komodor is the Continuous Kubernetes Reliability Platform, designed to democratize K8s expertise across the organization and enable engineering teams to leverage its full value.

Komodor’s platform empowers developers to confidently monitor and troubleshoot their workloads while allowing cluster operators to enforce standardization and optimize performance.

Specifically when it comes to AKS version upgrades, Komodor enables you to proactively monitor each cluster’s End-of-Life status, as well as its associated APIs. With Komodor, your infrastructure remains up-to-date and compliant, while preventing potential issues from occurring.

By leveraging Komodor, companies of all sizes significantly improve reliability, productivity, and velocity. Or, to put it simply – Komodor helps you spend less time and resources on managing Kubernetes, and more time on innovating at scale.

If you are interested in checking out Komodor, use this link to sign up for a Free Trial.