K8s Long Term Support (LTS) Releases?

General Discussions
1

Should kubernetes have long term support (LTS) releases?

Why / why not?

What would you want from an LTS? How would you use it? What support time frame would you hope for? How often would you want a new LTS? What criteria would you expect for patches that do (or do not) get back ported to an LTS?

What upgrade friction today makes folks want an LTS? Would that be better (or worse) if you tried upgrades every two to six years instead of every three to six months?

2

A Github issue have been created to continue and follow up this discussion.

3

I find it odd to reply to a github thread, but Iā€™m happy to if you all feel the feedback would be better there. Formally, I used to work for Linux Distribution company that built a Kubernetes Distribution. Kubernetes should not create a LTS release.

I often find those asking for an LTS are either one of two kinds of people. Either those that are building bespoke Kubernetes clusters by hand or a company building a distribution.

The former is fine, but thatā€™s the trade off to not using a distribution. So if you want an LTS of Kubernetes itā€™s plausibly because you want to prevent having to churn and test a bespoke deployment every quarter.

The latter are simply because building and testing distributions are hard (I led an engineering team doing just that), having upstream put a stake in the ground saying this is a long term support version shifts the burden of back-porting patches and maintenance from their distro team to the upstream.

Kubernetes is rolling fast and I know thatā€™s a bit of a meme about Kubernetes but itā€™s true. To sink into an LTS cycle is a huge overhead in coordination to support releases longer than already are. Honestly, the current model of what appears to be N+2 versions supported means you have nearly a year of support for whatever version you start with. In a project which releases 4 minor releases a year thatā€™s a decent buffer. If a distribution wants to claim they have an LTS Kubernetes, thatā€™s fine. However, thatā€™s simply their decision and they would need to field the work to do that.

In all honesty, having seen the work it takes to support an LTS distribution I wouldnā€™t want to wish that on a community like this, especially given itā€™s unique challenges coordinating large swaths of code in a purely community aspect.

4

I am inclined to agree with @marcoceppi and I manage somewhat of a ā€˜bespokeā€™ cluster (On-prem + Container Linux + Kubeadm provisioned).

Most of the folk Iā€™ve encountered desiring an LTS release (from an end-user perspective) fall into two categories:

  1. Want it because upgrading is a pain point, and itā€™s ā€˜easierā€™ to sit on one version as long as they can
  2. Have specific compliance or regulatory needs that require certifying the cluster

For problem 1, there are multiple efforts working on improving that specific friction point. Of them, most notably is probably the cluster-api. Kubeadm makes bootstrapping and managing a cluster MUCH easier, but it still requires some additional glue and hand-holding for HA or a nice seamless upgrade experience. Once upgrading becomes ā€˜trivialā€™ I suspect much of the complaints coming from this category will be resolved.

For 2, I think this will take a greater conversation regarding how regulatory groups want to sign-off on a cluster. Is it sufficient if the cluster passes all the security benchmarks (thinking CIS) and e2e tests after an upgrade? If so, thats an easily achievable goal. Iā€™ve also had conversations with auditors some wanted to treat the cluster and app(s) hosted on it as one entity when really much of the app portion should be done up the chain within the CI/CD system itself.

Both of those challenges I believe are solvable without burdening the community with the management of an LTS release.

5

FYI weā€™ve got a survey going through April on this topic: https://www.surveymonkey.com/r/kubernetes-support-survey-2019

2 Likes