Microsoft has long invested in the upstream Kubernetes community, and as our Azure team members have led and participated in the Kubernetes release process, we’ve listened to what our customers say about the pace of Kubernetes development. Today we are excited to announce the introduction of Azure Kubernetes Service (AKS) Long Term Support (LTS).
We’re hearing from customers across a variety of organizations, from healthcare to manufacturing and beyond, who need a longer window of stability. We’ve heard from ISVs that having to be on a constant treadmill to keep their environments in sync with community releases adds a significant burden to delivering value to their customers.
For organizations with multiple teams or complex environments, staying on top of upgrades can pose a significant challenge. With three releases happening each year and a year of support for any given release, updates require frequent action. LTS will help teams plan and test upgrades on a longer timeline, while staying on a supported Kubernetes version.
It is critically important for all Kubernetes users that when they choose to run their applications on versions of Kubernetes that are not maintained by the community that the entire stack from the operating system to the Kubernetes components are maintained and patched by their service provider. The only way to host your applications on a Kubernetes version that is out of community support is to either run without security updates, or to put significant effort into forking the version, and cherry picking or resolving security issues yourself.
Based on feedback from our customers, we decided to put a team together to do just that.
We will be forking and maintaining the Kubernetes codebase for the LTS version once it leaves community support and maintaining this in the open.
The first AKS version that can have Long Term Support will be 1.27, to be released in May 2023. While running a cluster at an LTS version, customers will receive support and security updates for two years from the GA date (instead of the usual one year).
We intend to restart the community’s kubernetes WG-LTS to collaborate across the ecosystem to collect requirements and define processes and tooling required for creating secure and stable long term support releases of Kubernetes in the future. https://github.com/aks-lts is a work in progress, and we welcome feedback and contributions.
Customers will be able to opt in to LTS support for Kubernetes 1.27 at any time, or spin up Kubernetes 1.27 clusters and node pools during that two year period.
Making upgrades simple and safe
Upgrading with confidence requires an understanding of how any change will affect your continuity of cluster operations. AKS supports fully automated in-place cluster upgrades (controlled via upgrade schedules) or manual in case you need more control over when these happen.
In order to make the upgrade process for Kubernetes minor versions easier, the objects in ETCD are automatically converted to the newer APIs. And now AKS will detect if you are using a deprecated API anywhere (for example operators or your code), and we will prevent the upgrade, and warn you in order to stop you from inadvertently breaking your applications. You can override to force the upgrade or correct the API usage and retry after a period of time.
You decide when to move from one Kubernetes version to another, allowing you to plan and test your migrations. For non-LTS clusters, each Kubernetes version is supported for 12 months. After 12 months, the minor version will shift to platform support only. Our new platform support policy provides customers with Azure infrastructure support while the cluster is in an n-3 version (where n is the latest supported AKS GA minor version). Platform support does not include anything related to Kubernetes functionality and components, but provides customers with additional support beyond what was previously provided for unsupported versions.
AKS will make the automatic upgrade of out of support clusters predictable to ensure they remain within a Kubernetes supported version. When a cluster in an n-3 version is about to drop to n-4, AKS will automatically upgrade the cluster to n-2. For example, Kubernetes v1.25 will be upgraded to v1.26 during the v1.29 GA release. For more information, see the AKS documentation.
We always recommend our customers stay within community support, and whether your needs are best served by an LTS Kubernetes release or an automatically upgraded cluster, Azure's support commitment to you is the same. Instead of a constant race to keep up with an ever-changing API surface while worrying about unpatched CVEs, Azure Kubernetes Service customers can grow their cloud native estates in confidence of their support and continuity.
For more information on Kubernetes version support on AKS, assess your options, and for pricing information, take a look at the Supported Kubernetes section on Azure Docs.
