4 ms·

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 ti

by DasIch 8y ago

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 https://m.youtube.com/watch?v=1xHmCrd8Qn8

darren0 8y ago
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.
- itsnotvalid 8y ago
  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.
- wikibob 8y ago
  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.
- rezeroed 8y ago
  Yes, we still have some 1.1.7s.
- falcolas 8y ago
  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.
  - toomuchtodo 8y ago
    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.
    - falcolas 8y ago
      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"?
      - deleted 8y ago
        [deleted]

by DasIch 8y ago

darren0 8y ago

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.

itsnotvalid 8y ago
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.
wikibob 8y ago
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.
rezeroed 8y ago
Yes, we still have some 1.1.7s.
falcolas 8y ago
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.
- toomuchtodo 8y ago
  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.
  - falcolas 8y ago
    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"?
    - deleted 8y ago
      [deleted]