Hacker News Reader

Comment by DasIch | Hacker News Reader

I don’t understand your argument. If you have lots of clusters, surely you’re upgrading using some kind of CD mechanism. So it shouldn’t make a difference in time to upgrade.

Zalando (disclaimer I work there, though not on K8S infrastructure. I just deploy to K8S) does upgrades this way: https://m.youtube.com/watch?v=1xHmCrd8Qn8

View on HN

In practice most people do not run k8s upgrades through a CD pipeline. They are much more conservative about it. This is not a technical issue, just a cultural one mainly. People plan and roll out upgrades. Most organization treat a cluster as a large pet. They would like to avoid upgrading if they can because it's viewed as a risk. Patch releases are not typically an issue, it is minor releases that cause concern.

So every 3 months is too fast for a lot of teams (again, not technical issue, this is culture of enterprise) so they may put off an upgrade. Once you do that the upgrade becomes more risky because there is obviously more change from 1 to 3 than 1 to 2.

What I'm describing is not an issue specific to k8s, this is just a general enterprise infrastructure issue and one of the many reasons enterprises like LTS releases.

I think most people would very much like to deploy cluster updates more frequently.

Unfortunately this is difficult because most distributions don't keep up with the release cadence.

One of (the most?) popular way to deploy Kubernetes is the Kops project. As far as I know there is nobody who is paid to work on Kops, thus the bugs and PR's don't get enough hours invested in them.

Distribution and packaging is very boring and fiddly grunt work, it would be wonderful if somehow we as a community could figure out how to fund full time work on a distribution in the OSS space. Perhaps CNCF could do a better job of funding this somehow.

It's a hard problem, because the organizations most suited to solving it are CoreOS/RedHat/Microsoft/Google/Amazon/etc, and they have a vested interest in putting that effort into making their hosted solutions a great experience instead.

Kubeadm looks like a great step in the right direction, but as far as I'm aware, there aren't any production quality distributions for installing clusters with it yet.

And, as mentioned in a sibling comment, as complex as the K8s project is now, upgrades break things. They regularly break APIs, CLI arguments, tooling, documentation, integrations, and just about everything else.

Having your entire k8s infrastructure go down due to a "oopsie" in an upgrade is a risk. And mitigating these risks takes time and effort.

As an ex-devops/infra guy, every day I'm ecstatic I don't have to wrangle k8s. These are not attributes of production infrastructure tooling. My hat is off to all of you in the trenches.

I still struggle with the idea that an infrastructure software version can go out of support within 6 months. I still recall the days where we would wait 6 months on a new version of software, just to let it settle and get its initial patches out of the way.

I hearken back to a snippet from a recent article:

> 2014: We must adopt microservices to solve all the problems with monoliths

> 2016: We must adopt Docker to solve all the problems with Microservices

> 2018: We must adopt Kubernetes to solve all the problems with Docker

What's next? "We must adopt Rancher to solve all the problems with K8s"?

It's also that not all services used together may work on the latest version of k8s. For example, one of the services can only support up to 1.11 and need updates to use 1.12, then you suddenly cannot deploy 1.12 to those clusters. I think in terms of LTS it's more about having stable APIs for developing.

Yes, we still have some 1.1.7s.

Reply on news.ycombinator.com