5 ms·

It's about time for a Kubernetes to do LTS releases. 3 month release cycle and support for only 9 months is too quick for companies given that in practice comp

It's about time for a Kubernetes to do LTS releases. 3 month release cycle and support for only 9 months is too quick for companies given that in practice companies are running lots of clusters, not just 1 or 2 big clusters.

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]
outime 8y ago
If your concern is about manually updating a lot of clusters, then there are many providers (GCP, AWS, DO...) offering managed solutions which most likely will handle the updates for you.
manigandham 8y ago
Kubernetes already has many vendors that provide packaged distributions and long-term support if you want it. If you use the managed hosting/cloud providers then updates are also automatic and easy.
- darren0 8y ago
  I happen to be one of those vendors. I don't really view it as a good thing though. It's not good if everybody has to buy different forks of Kubernetes from vendors. A point of reference, Amazon EKS only runs 1.10 which will not be supported by the community in 3 months. So not all managed services are really keeping up.
  - manigandham 8y ago
    Ah, you're from Rancher. Great product, but isn't this exactly the problem space you serve? How many of the K8S vendors are selling distributions vs support plans? Or are they always entangled? And if the community did do LTS, isn't that just shifting the work to open-source maintainers rather than focused and paid vendors?
  - raesene9 8y ago
    Yeah having forked k8s will be bad. Back-porting possible security fixes could be tricky and having multiple companies have to do it, would be painful.
- raesene9 8y ago
  For on premises Kubernetes who do you know of who will provide committments to support k8s after the main project stops? As far as I was aware of all the on-prem options cleave to the main project support lifecycle...
  - gk1 8y ago
    https://www.gravitational.com/telekube https://www.gravitational.com/telekube ?
technofiend 8y ago
I mean one could argue that anything hosted on k8s should be reproducible anyway. I completely rebuild my k8s servers on a rolling two week cycle. The pain from that forces people to check in everything they need because if they don't it'll be gone very soon. And still it's a bit of a battle to get people to test new versions of things, k8s included. "But it's working" is as much of a rallying cry as it ever was, "cloud" or no.
- jasonrm 8y ago
  Curious about the details of how you rebuild/deploy your k8s servers. Any chance you've already written about this somewhere?
  - technofiend 8y ago
    Nothing special. Just cobbler to generate the iso and kubespray to install the cluster. Between company policy on social media and internal weirdness I can't really write a GitHub or Medium contribution to HN that anyone would want to consume anyway. However I do plan to document what I've learned in a generic sort of "If you use Digital Ocean, this is how to do X, Y, Z" way.
    - jasonrm 8y ago
      Thanks! I haven't seen cobbler before, so that's certainly something I'll take a look at. Toyed with matchbox before, but didn't end up using it. Not using DigitalOcean currently, but look forward to reading that someday.

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]

outime 8y ago

If your concern is about manually updating a lot of clusters, then there are many providers (GCP, AWS, DO...) offering managed solutions which most likely will handle the updates for you.

manigandham 8y ago

Kubernetes already has many vendors that provide packaged distributions and long-term support if you want it. If you use the managed hosting/cloud providers then updates are also automatic and easy.

darren0 8y ago
I happen to be one of those vendors. I don't really view it as a good thing though. It's not good if everybody has to buy different forks of Kubernetes from vendors. A point of reference, Amazon EKS only runs 1.10 which will not be supported by the community in 3 months. So not all managed services are really keeping up.
- manigandham 8y ago
  Ah, you're from Rancher. Great product, but isn't this exactly the problem space you serve? How many of the K8S vendors are selling distributions vs support plans? Or are they always entangled? And if the community did do LTS, isn't that just shifting the work to open-source maintainers rather than focused and paid vendors?
- raesene9 8y ago
  Yeah having forked k8s will be bad. Back-porting possible security fixes could be tricky and having multiple companies have to do it, would be painful.
raesene9 8y ago
For on premises Kubernetes who do you know of who will provide committments to support k8s after the main project stops? As far as I was aware of all the on-prem options cleave to the main project support lifecycle...
- gk1 8y ago
  https://www.gravitational.com/telekube https://www.gravitational.com/telekube ?

technofiend 8y ago

I mean one could argue that anything hosted on k8s should be reproducible anyway. I completely rebuild my k8s servers on a rolling two week cycle. The pain from that forces people to check in everything they need because if they don't it'll be gone very soon. And still it's a bit of a battle to get people to test new versions of things, k8s included. "But it's working" is as much of a rallying cry as it ever was, "cloud" or no.

jasonrm 8y ago
Curious about the details of how you rebuild/deploy your k8s servers. Any chance you've already written about this somewhere?
- technofiend 8y ago
  Nothing special. Just cobbler to generate the iso and kubespray to install the cluster. Between company policy on social media and internal weirdness I can't really write a GitHub or Medium contribution to HN that anyone would want to consume anyway. However I do plan to document what I've learned in a generic sort of "If you use Digital Ocean, this is how to do X, Y, Z" way.
  - jasonrm 8y ago
    Thanks! I haven't seen cobbler before, so that's certainly something I'll take a look at. Toyed with matchbox before, but didn't end up using it. Not using DigitalOcean currently, but look forward to reading that someday.