5 ms·

That's not how LTS is supposed to work. You should be able to uograde effortlessly with minimum risk. If you're at a point where a patch for LTS looks like an

by x86x87 3y ago

That's not how LTS is supposed to work. You should be able to uograde effortlessly with minimum risk. If you're at a point where a patch for LTS looks like an upgrade to the new version you've screwed up LTS. Also, getting to the point of having an LTS and actually providing the support is expensive. You need experts that can backport security fixes and know the product inside out.

sofixa 3y ago
> That's not how LTS is supposed to work. You should be able to uograde effortlessly with minimum risk. How do you do that on something as complex and with as many moving parts as Kubernetes? And how do you as an operator update that many things without checking there's no breaking changes in the patch?
- x86x87 3y ago
  bingo! how do you do it? and do you want that kind of complexity to begin with?
  - sofixa 3y ago
    Don't ask me, I'm firmly in the HashiCorp Nomad camp: https://atodorov.me/2021/02/27/why-you-should-take-a-look-at-nomad-before-jumping-on-kubernetes/ https://atodorov.me/2021/02/27/why-you-should-take-a-look-at... (Note: quite old, some things are no longer true most notably around Nomad downsides)
    - rigrassm 3y ago
      I'm with you, Nomad is highly underrated!
- Rantenki 3y ago
  We upgrade our distros pretty much fearlessly, all the time. While I have had breakage from Kernel upgrades, they've been very rare (and generally related to third party closed drivers). Kubernetes is _not_ more complicated than the Linux kernel, but it is much more dangerous to upgrade in place.
  - eddythompson80 3y ago
    > Kubernetes is _not_ more complicated than the Linux kernel, but it is much more dangerous to upgrade in place. eh, the kernel is an incredibly mature project with 1 machine scope. The kernel also has decades of operating systems research and literature to build on. Kubernetes in comparison is new, distributed and exploring uncharted territory in terms of feature set and implementation. Sometimes bad decisions are made, and it's fair to not want to live with them forever. The kernel project looks very different today than it did in 1999. There is a happy medium though, especially that Kubernetes is kinda far from it.
    - x86x87 3y ago
      Spoiler alert: k8s is not in uncharted territory. Erlang and its runtime discovered and solved most of the problems in the 80s. We are slowly rediscovering this the same way react discovered the event loop that Windows had discovered in the 90s.
      - eddythompson80 3y ago
        Erlang solved the problem by making a custom VM that abstracts the network away for the most part and is pretty opinionated about how you do that. Kubernetes is not that. I don't see how Erlang is relevant here. You can run Erlang applications on kuberntes, not the other way around.
- jen20 3y ago
  My answer is simple: don't. Use something far simpler and with fewer moving parts than Kubernetes, and something where crucial parts of the ecosystem required to make things even basically work are not outsourced to third party projects. Nomad is a good solution.
freedomben 3y ago
I don't see anywhere that GP said an LTS patch would take effort. They said the upgrade path to the next LTS would. If you are talking about upgrade from LTS to LTS, can you give an example project where that is effortless? And if so, how do they manage to innovate and modernize without ever breaking backwards compatibility?
- x86x87 3y ago
  Here: "it's easier to go from 1.20.1 to 1.20.5 than to 1.21, because there's less chance of breakage and less things that will change, but the process is pretty much the same" LTS to LTS is another story. But the point is that L=LongTerm so in theory you're only going to do this exercise twice in a decade. > manage to innovate and modernize without ever breaking backwards yeah. fuck backwards compatibility. that is for suckers. how about stopping the madness for a second and thinking about what you are building when you build it?
  - pixl97 3y ago
    > in theory you're only going to do this exercise twice in a decade. So I've seen things like this in corporations many times and it typically works like this... Well trained team sets up environment. Over time team members leave and only less senior members remain. They are capable of patching the system and keeping it running. Eventually the number of staff even capable of patching the system diminishes. System reaches end of life and vendor demands upgrading. System falls out of security compliance and everything around it is an organizational exception in one way or another. Eventually at massive cost from outside contractors the system gets upgraded and the cycle begins all over again. Not being able to upgrade these systems is about the lack of and loss of capable internal staff.
    - x86x87 3y ago
      What is the cost of keeping it "up to date" vs doing this exercise once every say 7 years? Are most software systems even around for 7 years?

by x86x87 3y ago

sofixa 3y ago

> That's not how LTS is supposed to work. You should be able to uograde effortlessly with minimum risk. How do you do that on something as complex and with as many moving parts as Kubernetes? And how do you as an operator update that many things without checking there's no breaking changes in the patch?

x86x87 3y ago
bingo! how do you do it? and do you want that kind of complexity to begin with?
- sofixa 3y ago
  Don't ask me, I'm firmly in the HashiCorp Nomad camp: https://atodorov.me/2021/02/27/why-you-should-take-a-look-at-nomad-before-jumping-on-kubernetes/ https://atodorov.me/2021/02/27/why-you-should-take-a-look-at... (Note: quite old, some things are no longer true most notably around Nomad downsides)
  - rigrassm 3y ago
    I'm with you, Nomad is highly underrated!
Rantenki 3y ago
We upgrade our distros pretty much fearlessly, all the time. While I have had breakage from Kernel upgrades, they've been very rare (and generally related to third party closed drivers). Kubernetes is _not_ more complicated than the Linux kernel, but it is much more dangerous to upgrade in place.
- eddythompson80 3y ago
  > Kubernetes is _not_ more complicated than the Linux kernel, but it is much more dangerous to upgrade in place. eh, the kernel is an incredibly mature project with 1 machine scope. The kernel also has decades of operating systems research and literature to build on. Kubernetes in comparison is new, distributed and exploring uncharted territory in terms of feature set and implementation. Sometimes bad decisions are made, and it's fair to not want to live with them forever. The kernel project looks very different today than it did in 1999. There is a happy medium though, especially that Kubernetes is kinda far from it.
  - x86x87 3y ago
    Spoiler alert: k8s is not in uncharted territory. Erlang and its runtime discovered and solved most of the problems in the 80s. We are slowly rediscovering this the same way react discovered the event loop that Windows had discovered in the 90s.
    - eddythompson80 3y ago
      Erlang solved the problem by making a custom VM that abstracts the network away for the most part and is pretty opinionated about how you do that. Kubernetes is not that. I don't see how Erlang is relevant here. You can run Erlang applications on kuberntes, not the other way around.
jen20 3y ago
My answer is simple: don't. Use something far simpler and with fewer moving parts than Kubernetes, and something where crucial parts of the ecosystem required to make things even basically work are not outsourced to third party projects. Nomad is a good solution.

freedomben 3y ago

I don't see anywhere that GP said an LTS patch would take effort. They said the upgrade path to the next LTS would. If you are talking about upgrade from LTS to LTS, can you give an example project where that is effortless? And if so, how do they manage to innovate and modernize without ever breaking backwards compatibility?

x86x87 3y ago
Here: "it's easier to go from 1.20.1 to 1.20.5 than to 1.21, because there's less chance of breakage and less things that will change, but the process is pretty much the same" LTS to LTS is another story. But the point is that L=LongTerm so in theory you're only going to do this exercise twice in a decade. > manage to innovate and modernize without ever breaking backwards yeah. fuck backwards compatibility. that is for suckers. how about stopping the madness for a second and thinking about what you are building when you build it?
- pixl97 3y ago
  > in theory you're only going to do this exercise twice in a decade. So I've seen things like this in corporations many times and it typically works like this... Well trained team sets up environment. Over time team members leave and only less senior members remain. They are capable of patching the system and keeping it running. Eventually the number of staff even capable of patching the system diminishes. System reaches end of life and vendor demands upgrading. System falls out of security compliance and everything around it is an organizational exception in one way or another. Eventually at massive cost from outside contractors the system gets upgraded and the cycle begins all over again. Not being able to upgrade these systems is about the lack of and loss of capable internal staff.
  - x86x87 3y ago
    What is the cost of keeping it "up to date" vs doing this exercise once every say 7 years? Are most software systems even around for 7 years?