WG-Creation-Request: WG LTS
Jeremy Rickard
For many Kubernetes users, the frequency of Kubernetes releases is hard to keep up with. Surveys indicate that many users are running clusters that have fallen out of the yearly support window and in many cases are running clusters that have been out of support for multiple years. The frequency of releases, combined with the current upstream support policy, makes it difficult for some Kubernetes users to remain on supported versions, which can have an overall impact on security and reliability for these users. Additionally, users currently either need to migrate to newer, supported versions or undertake stepwise upgrades across potentially many versions in order to bring their clusters into support.
Previously, a working group (wg long term support (LTS)) was created to address these needs. Some things that resulted from this working group included:
The working group eventually reached a logical stopping point and was disbanded in 2020.
What is the exact problem this group is trying to solve?
This working group proposes to revisit topics related to the operation and support of Kubernetes, including in-use versions, particularly the use of end of life (EOL) versions of Kubernetes and difficulties or constraints around deployment and upgrade, in order to better understand what “Long Term Support” might mean for the project, those who support Kubernetes, and end-users.
To do this, we will collect information related to the needs and wants of end-users and people supporting Kubernetes. Non-exhaustive examples include:
in-use versions (in the form of a user/vendor survey) and reasons for sticking on those versions
constraints on deployment and upgrade patterns / timelines (e.g. edge deployments, regulated industries, retail, etc)
expected/required support periods from users/vendors
support periods of core Kubernetes dependencies
support periods of other components required to run Kubernetes clusters (OS, network, storage, etc)
what users/vendors are currently doing to support releases past OSS EOL
what do users/vendors do with EOL clusters today? what would they do if EOL was extended by N months/years?
With this information, we will brainstorm and investigate changes the Kubernetes project could make to help address identified issues, to determine feasibility, benefits, costs, and prerequisites. A non-exhaustive set of changes to investigate include:
lengthen support period for all minor versions
lengthen support period for specific minor versions
apply security fixes to release branches past current EOL without cutting additional patch releases
apply security and "critical" fixes to release branches past current EOL without cutting additional patch releases
expand supported skew
improve supported upgrade patterns for clusters at EOL
What is the artifact that this group will deliver, and to whom?
Recommend changes Kubernetes sigs can make that will provide broad benefits in a sustainable/affordable way. This would likely take the form of one or more KEPs.
Recommend ways users/vendors who want to maximize Kubernetes support can consume Kubernetes
How does the group know when the problem solving process is completed, and it is time for the Working Group to dissolve?
Upon creation, the WG will create a detailed charter that includes the specific goals identified above and will need to periodically reevaluate progress against the stated goals. Several vendors plan on working on this problem independently and the WG will evaluate progress against a common vision / definition and will propose dissolving the working group if we are not able to make meaningful progress in TBD timeframe. Likewise, if we are able to produce related KEPs and other guidance, we will dissolve the working group.
Who are all of the stakeholder SIGs involved in this problem this group is trying to solve?
Any effort to increase the length of time that a release is supported, or to define specific “LTS” releases, will require input and support from all SIGs.
However, the following SIGs would likely be the most direct stakeholders and we would like to ask for sponsorship for the working group from them:
Architecture (https://github.com/kubernetes/community/tree/master/sig-architecture)
K8s Infra (https://github.com/kubernetes/community/tree/master/sig-k8s-infra)
Release (https://github.com/kubernetes/community/tree/master/sig-release)
Testing (https://github.com/kubernetes/community/tree/master/sig-testing)
Additionally, the Security Response Committee (https://github.com/kubernetes/community/tree/master/committee-security-response) would likely be a stakeholder in the problem the WG is trying to solve.
What are the meeting mechanics (frequency, duration, roles)?
Upon creation of the working group, we will leverage a mailing list to solicit more interest and decide upon a meeting cadence. These meetings will likely start as bi-weekly, but we will adjust based on feedback from participants.
Does the goal of the Working Group represent the needs of the project as a whole, or is it focused on the interests of a narrow set of contributors or companies?
This working group intends to represent the needs of Kubernetes users that require longer term support, while also balancing those needs with costs and other impacts felt by Kubernetes contributors.
Who will chair the group, and ensure it continues to meet these requirements?
Proposed initial chairs:
Micah Hausler (AWS)
Jordan Liggitt (Google)
Jeremy Rickard (Microsoft)
Is diversity well-represented in the Working Group?
During the contributor summit at KubeCon EU 2023, individuals from the following companies (I am sorry if I missed your company) indicated a desire to participate in the working group:
Apple
AWS
Canonical
DaoCloud (https://klts.io)
Google
Kubermatic
Microsoft
Oracle
Red Hat
VMware
This includes major vendor companies as well as a substantial end user. It is likely that additional end users would be interested as well and we will welcome participation and support from additional end users or anyone else that is interested!
Thank you!
