Revive WG-LTS

[jeremyrickard]

Describe the issue

Microsoft recently announced that the Azure Kubernetes Service would being offering long term support (LTS) for Kubernets 1.27. Some individuals at KubeConEU 2023 Contributor Summit indicated that they were either working on something similar or planned to do so, which resulted in a lively a 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.

The working group governance covers creating and disbanding a WG, but not necessarily reviving a previously disbanded working group, so I'm opening this issue as a placeholder to discuss reviving the WG and for tracking potential items outline in the SIG/WG Lifecycle Doc (https://github.com/kubernetes/community/blob/master/sig-wg-lifecycle.md). I assume we'd just treat this as creation of a new WG, so I'll also send an email to dev@kubernetes.io per the lifecycle doc.

This is a topic that requires input from a number of SIGs, I've included a few of them below.

/sig architecture release k8s-infra testing

[jeremyrickard]

/committee steering

[kmova]

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.

💯

[aojea]

/cc

[liggitt]

I'm happy to help with this.

The first wg-lts identified an annual support period as being valuable to a wide range of users, and identified go as a particularly important dependency that didn't match Kubernetes' support window. Focusing on those pain points, we drove improvements over the past few years (KEP-1498 expanded Kubernetes support from 9 to 14 months, KEP-3744 resolved k8s/go support drift) in ways that benefited everyone without significantly increasing community costs.

Another iteration of the working group to reassess wants/needs of end users and people supporting Kubernetes, and the costs/blockers to the community or vendors supporting those wants/needs seems valuable and timely.

While I'm personally skeptical that the community can afford to support additional versions, and I think a "same thing but for longer" approach mostly just time-shifts issues people currently have N months into the future, I'm on board with identifying/driving efforts that provide broad benefit to users, specifically improve the lives of users/vendors that need to support Kubernetes longer than OSS currently does, and can be afforded by the community.

[ShashankGirish]

I'd be happy to help with this effort too.

[humblec]

@jeremyrickard as discussed, I am more than happy to help on this effort and to get WG LTS back in action.

[hakman]

I would be interested in this topic also.
Should upgrade be supported from one LTS to the next, without going through intermediate releases?
/cc

[liggitt]

Should upgrade be supported from one LTS to the next, without going through intermediate releases?

specific questions like that are what the wg will research, get input, and give feedback on

[hakman]

@liggitt Btw, maybe sig-cluster-lifecycle should be involved also
/cc @justinsb

[liggitt]

@liggitt Btw, maybe sig-cluster-lifecycle should be involved also

I think this touches pretty much every sig :-)

[ChaoyiHuang]

I would like to provide some input from telecom industry to help revive the WG LTS, or say, why Kubernetes LTS is needed.

Before describe the input in next section, the rough idea of Kubernetes LTS look like this, it will help telecom industry a lot.

1. Keep three Kubernetes releases per year as the community is doing today, no change on the release scheduling.

2. One LTS release one year, for example, Kubernetes 1.27 as the LTS release in 2023, supported by the community a little longer up to 24 months(just prolong 10 months support). For other two regular releases, Kubernetes 1.28 and Kubernetes 1.29, will be supported by the community as usual 14 months. LTS release in 2024 is expected to be 1.30, one year interval between two LTS releases, this will help produce predictable LTS release plan.

3. For those who have fast upgrading requirements on Kubernetes, they can evolve their product system as what they are doing today, LTS mechanism will not introduce negative impact on these players. For those who rely on 2 year LTS Kubernetes release, 10 more months support will not produce Kubernetes fragmentation in the market, they still need to upgrade Kubernetes every year at least.

[ChaoyiHuang]

Why Kubernetes LTS can help telecom industry:

Without LTS release, a kubernetes release, which just providing 14 months support, is usually already or almost EOLed before this release can be upgraded in production.

In telecom industry, some operators purchase Kubernetes distribution from some independent vendors or public cloud providers, and telecom applications for example 5G products, from other vendors(not only one, maybe multiple vendors).

Once a new Kubernetes release published, the distribution integrators need time to observe, test and integrate its distribution, to make sure the release is secure and stable enough.

After Kubernetes distribution released, telecom application vendors need to test thier applications are compatible with the new distribution or not. If application has to be modifed, then it'll take much longer time. The test including function, performance, reliability, security aspect etc.

Telecom application is not working alone, for example, for 5G applications, they usally need to do interoperability test to ensure application can talk with each other correctly, especially if these applications from different vendors. In telecom industry, applications from multi-vendors is very common strategy for telecom operators.

Kubernetes distribution and telecom applications should be then delivered to telecom operators. Integration test, interoperability etc test by operators will be done, to make sure all parts of the telecom network, from hardware/platforms to applications, they can perform well in production system.

Even if these artifacts are ready, upgrading the production system still take long time for all sites(maybe 10s, 100s, 1000s) to be upgraded to the new Kubernetes release. If telecom applications running in production are not compatible with the new k8s distribution, have to upgrade telecom applications first, to make sure the new telecom applications are compatible to both the old and new kubernetes releases, then the underlying kubernetes can be upgraded to a new release, for the application is ready now. Of course, It's not able to upgrade telecom application tonight, then upgrade the underlying Kubernetes tomorrow, have to watch the healthy and stability of the telecom service for some period. It has to be done gradually.

For telecom applications, for example, 5G, they are mission critical applications, need to provide 5 nine availability. Therefore, it's not able to upgrade all applications / kubernetes in one night for all sites, have to consider/distribute the failure risk. In some countries, the SLA is monitored by the goverment, telecom network outage may face huge fine.

The last site to upgrade which run the old Kubernetes release have to stay in the production for quite long period, 14 month community support is not longer enough.

That's why mentioned at the beginning, without LTS release, a kubernetes release is usually already or almost EOLed before this release can be upgraded in production.

Just as what mentioned, in telecom industry, one telecom applications vendor, have to consider its applicaions can run over multiple k8s distributions, with different host OS, different kernel releases, and different driver versions, the compatibility cost is too high to port/test its applicaions run on every kubernetes release. If n telecom applicaions, and m k8s distributions, and 3 kubernetes release per year, then the compatibility test/port cost is n x m x 3.

If Kubernets provide LTS release, then, all telecom application vendors, k8s distribution vendors, operators can be aligned to the Kubernetes LTS release, the compatibility test cost will be reduced greatly to every player in telecom industry, 66% reduction. LTS mechanism also provide predictable integration planning for all players.

With Kubernetes LTS mechnism, though kubernetes is not upgrading every 4 months, telecom applications can still upgrade frequently to introduce new feature to end user with same Kubernetes release, whic need no additional compatibility test.

For those who have fast upgrading requirements on Kubernetes, they can evolve their product system as what they are doing today, upgrade Kubernetes every release as usual, LTS mechanism will not introduce negative impact on these players.

[aojea]

If Kubernets provide LTS release, then, all telecom application vendors, k8s distribution vendors, operators can be aligned to the Kubernetes LTS release, the compatibility test cost will be reduced greatly to every player in telecom industry, 66% reduction.

is the telecom industry planning to add resources (as in money and people) to the project to make it happen ?

[ritazh]

I'm excited about this!

On the tactical side, for folks who are following this issue at home, how can they start getting more involved? Specifically when is the next WG meeting? Can we use any of the old mailing list, Google docs, Zoom meeting, GitHub directory? Since this is a revival of an old WG, the existing governance docs didn't cover this case (yet).

[liggitt]

I think the easiest/fastest approach is to just walk the creation path, so follow https://github.com/kubernetes/community/blob/master/sig-wg-lifecycle.md#prerequisites-for-a-wg

For folks interested, look for an email to dev@kubernetes.io with a link to a PR to https://github.com/kubernetes/community/blob/master/sigs.yaml for steering and sponsoring sigs to ack

Once that's done, we could revive the mailing list / slack, figure out a meeting cadence, etc

[mrbobbytables]

Just wanted to chime in and +1 Jordan's comments on next steps as a steering committee member.

Folks can freely talk about it, but to get things going officially the charter/PR/acks from sponsoring sigs need to happen first.

[pacoxu]

We start a similar project https://github.com/klts-io/kubernetes-lts last year and focus on CVEs and critical issues only.

[ChaoyiHuang]

If Kubernets provide LTS release, then, all telecom application vendors, k8s distribution vendors, operators can be aligned to the Kubernetes LTS release, the compatibility test cost will be reduced greatly to every player in telecom industry, 66% reduction.

is the telecom industry planning to add resources (as in money and people) to the project to make it happen ?

yes, planning to add resources

[detiber]

@liggitt Btw, maybe sig-cluster-lifecycle should be involved also

I think this touches pretty much every sig :-)

Just adding agreement here that SIG Cluster Lifecycle should be one of the key stakeholders/sponsors for this effort.
/cc @vincepri @neolit123 @CecileRobertMichon @fabriziopandini

[vincepri]

Thanks for the ping @detiber !

Definitely interested in this effort personally; for SIG sponsorship let's queue up a discussion for the community meeting.

[jeremyrickard]

I sent a message to k-dev: https://groups.google.com/a/kubernetes.io/g/dev/c/qWsMPMDqCFQ

[jberkus]

As one of the leads of the former WG-LTS, +1 on restarting the WG under new leadership.

We will need to revise the charter of the WG, incorporating the feedback from the unconference session.

[logicalhan]

Also interested.

[youngnick]

As another lead of the former WG-LTS, I'm also +1, and would definitely like to be involved.

[neoaggelos]

I'd be very happy to join this effort and contribute to the best of my abilities.

[dims]

+1 from myself and on behalf of sig-arch

cc @derekwaynecarr @johnbelamaric

[vincepri]

+1 from SIG Cluster Lifecycle, today's community meeting (recording): chairs and tech leads were overall very supportive of the effort, and would like to be one of the primary stakeholders and sponsors.

[chris-short]

Strong +1.

How does one get plugged in to help?

[munnerz]

I would also like to participate and represent end-user interests in the LTS discussion :)

[wzshiming]

/cc

[reylejano]

+1
I'm interested in helping

[sftim]

@reylejano do you have capacity to also represent SIG Docs for LTS (at least the WG kickoff)?

[hannibalhuang]

+1

[rjsadow]

/cc

[reylejano]

@reylejano do you have capacity to also represent SIG Docs for LTS (at least the WG kickoff)?

@sftim , yes I have capacity

[fedebongio]

/cc

[bharitwal]

+1

I would like to be involved as well.

[dongjiang1989]

very interested! I'm also +1, and would definitely like to be involved.

[ramrodo]

+1
Interesed in helping :)

[bryan-strassner]

+1, Very interested in the aspects of getting 3rd party community (e.g., CNI) support aligned with LTS timelines as well.