WG-Creation-Request: WG LTS

Skip to first unread message

Jeremy Rickard

May 1, 2023, 11:11:50 AM5/1/23
to d...@kubernetes.io
Hello everyone,

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.

At the KubeCon EU 2023 Contributor Summit, several vendor teams discussing LTS indicated that they were either working on an “LTS” offering or planned to do so, which resulted in an unconference session discussing Kubernetes LTS. There appeared to be general agreement from those in attendance that "longer" support would be beneficial to the community and that some of the issues that were blockers/limitations to the previous iteration of wg-lts are no longer as impactful as they once were, but that additional work remains and there are still things to work through. The general consensus was also that the #1 action item from that unconference session was that we should revive WG-LTS to work on a new charter and to collaborate on the outstanding issues to try and identify a more detailed vision for what a community supported LTS would entail.

I have opened a tracking issue in kubernets/community and we have answered the following questions from the working group governance docs to initiate discussion about this proposed working group and welcome feedback:

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:

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!

Vince Prignano

May 1, 2023, 2:52:38 PM5/1/23
to dev, Jeremy Rickard, fabrizio...@gmail.com, neol...@gmail.com, just...@google.com, cecile...@gmail.com
+1 from my side, SIG Cluster Lifecycle would be a great home for this effort and would like to help out as initial chair to facilitate connections.

/cc sig cl leads

Jeremy Rickard

Jul 21, 2023, 1:39:36 PM7/21/23
to d...@kubernetes.io, wg-...@kubernetes.io
Hello everyone,

I am following up to this email to share that the PR to recharter the LTS Working Group was recently merged: https://github.com/kubernetes/community/pull/728. Thank you to everyone who showed interest and support for restarting this working group. 

You can find the charter and README for the working group at http://git.k8s.io/community/wg-lts 

The #wg-lts slack channel has been reactivated on Kubernetes slack and a new mailing list has been created at: https://groups.google.com/a/kubernetes.io/g/wg-lts. If you are interested in participating in the working group, please join us in those locations. 

In order to identify some possible meeting times, I have created a doodle https://doodle.com/meeting/participate/id/aO8GpwGb to try and identify some times that might work for initial meetings. These initial times only cover some time zones and we can investigate having alternating meetings to be more inclusive going forward. 

Thank you again, and see you on the new mailing list and slack. 

Humble Devassy Chirammal

Jul 22, 2023, 6:29:34 AM7/22/23
to dev, Jeremy Rickard, wg-...@kubernetes.io
Awesome! Looking forward to collaborating on this initiative. 
Reply all
Reply to author
0 new messages