Rhythms of life follow a timeless pattern, with seeds of growth followed by transformational renewal, and software is an art that imitates life. Each calendar year brings three releases of Kubernetes, with fanfare around API changes and excitement about feature graduations. And every time a new version is released, the oldest supported version (now a year old) approaches the end of its updates (with considerably less celebration). Joy about new options may be overshadowed by concerns about migration and stability. As members of the community, we at Microsoft Azure are galvanizing the effort to address this issue and create a shared solution.

Challenges for end users (large or small, enterprise or not) include their Kubernetes clusters falling out of support or their organization spending the time and resources to accomplish more frequent upgrades; neither scenario is ideal. In regulated industries, requirements around certification mean that timelines do not allow a Kubernetes version to be deployed before it reaches its end of life and no longer receives updates. But even if you're not in a regulated industry, you need to fit upgrades in around your organization's other goals. To address this, the Kubernetes community is collaborating in a working group on Kubernetes Long Term Support (LTS), in order to provide the necessary support that would allow for upgrades on a longer timeline, selecting LTS releases and ensuring there is an upgrade path between them.

A past iteration of this working group created positive forward movement; the Kubernetes project moved to a year of support (when it had previously provided only nine months) after careful deliberation, with this change taking effect in Kubernetes 1.19. Following that, work continued that had a meaningful impact on upgrading clusters, including reducing the number of releases per year and enabling only stable features by default. The previous LTS working group's efforts ended with the support period currently remaining at one year: it's an improvement, but we can do better.

Kubernetes community surveys from 2023, 2022 and 2021 consistently show that the majority of Kubernetes installations are running versions already out of support or soon to be, which indicates that one year is too short for a complete upgrade cycle. Drawing from our experience with launching AKS LTS beginning with Kubernetes 1.27, Microsoft Azure team members started the LTS conversation again in the upstream community at the Kubernetes Contributor Summit in May 2023, to enthusiastic acclaim. We know that a community solution would ultimately serve the Kubernetes end users best, and we are committed to exploring how to accomplish it. This new WG-LTS has a goal of defining what it would mean to offer longer support than the current one year, considering feasibility of changes to the Kubernetes project and defining necessary technical prerequisites, while looking at the cost and benefit tradeoffs. Considerable effort is needed just in documenting all the changes necessary for this to be possible, but the potential benefits include positive outcomes like the possibility of skipping more versions and having longer periods of support.

Kubernetes Special Interest Groups managing different parts of the Kubernetes ecosystem are involved in the LTS project; these SIGs range from SIG Release to SIG Architecture to SIG Cluster Lifecycle and beyond. Meeting every other week, the working group members bring their perspectives from a multitude of geographies and employers, whether end user, vendor, or community member from any background, in order to create the best outcomes for all Kubernetes users. Challenges faced by users are being identified, including long dependency update chains and vendor update cycles that are at odds with current support periods.  Also being discussed are the extensive testing and certification programs found in regulated environments, which often need to be completed for each combination of control plane and worker nodes. These requirements are often very challenging, if not impossible, to complete within a given release cycle.

We are hopeful that the energy and excitement in WG-LTS will produce results for the community in the form of viable long-term Kubernetes release support. End users need their LTS experience to be consistent and reliable, and working together across providers is how we make this possible. Ecosystem projects from Prometheus to the Linux kernel itself offer LTS versions, and Kubernetes is ready to take its place in that company, where the Kubernetes LTS project will serve as an example of stability and long-term usability. We need to hear from you about your LTS needs; please give us your input in the periodic WG-LTS meetings or at KubeCon as we survey the community about LTS requirements. Let's work together to create the LTS that best meets your needs; Kubernetes LTS will only be successful when everyone, from regulated industries to seasonal retailers, from high-performance research to essential services can all have their needs met!

++

Join us at KubeCon + CloudNativeCon North America this November 6 - 9 in Chicago for more on Kubernetes and the cloud native ecosystem. 

##

ABOUT THE AUTHOR

Jeremy Rickard, principal software engineer at Microsoft

Jeremy Rickard is a principal software engineer at Microsoft, where he works on supply chain security projects in the Azure Container Upstream team. He is also a chair for SIG Release, a co-chair for the Long Term Support (LTS) working group, and was the release lead for Kubernetes 1.20. He previously worked on Kubernetes platforms at Apple and VMware.