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.