10 ms·

Sounds like Digital Ocean was the problem, not Kubernetes. Been running managed Kubernetes in GCP for years without any issues. They are bugging me to update

Sounds like Digital Ocean was the problem, not Kubernetes. Been running managed Kubernetes in GCP for years without any issues. They are bugging me to update for some time now, but I don't think they would force an update on me.

figassis 4y ago
Something is always the problem. With a VPS, you don’t usually have to worry about DO being a problem. You pay your bills, your server stays up. Maybe if you don’t update you might get hacked, but killed by provider update is not a failure mode of VPSs. I use k3s on bare metal. I’ve tried to run k8s so many times before and they all failed at some point in ways that didn’t inspire confidence. Mostly etcd became a mess, so this time I’m running k3s with a Postgres datastore that I can actually look at, reason about, backup and independently make HA, with a plus of not having to run arcane commands to manage the cluster that runs my cluster. I once tried nomad because it claimed to be simpler. I stopped when I realized I’d also have to use multiple clusters to run a cluster (nomad+consul). I use k3s because I build apps for multiple clients and I like the flexibility that it gives me in running servers like cattle. My point is that these orchestrators need to start decreasing the enormous amount of risk they add to any project.
tinco 4y ago
I hope you're right, I haven't had time to look at the same warning for 6 months now. There was a hard deadline on it in February and it came and went. The backwards incompatible Kubernetes api updates are a PITA. I know they said "beta", but if you literally have a version field in your manifest format, why ever deprecate a way of configuring something? They could just have operators translate the configs automatically on the fly.
- Rantenki 4y ago
  >They could just have operators translate the configs automatically on the fly How do they test that across the infinite number of permutations of configurations and deployments of K8S in the field though? It'll work for some people on the happy path, but it's really hard to maintain over time. Worse, it'll break randomly at some point in the future that is hard to predict, instead of at some publicly announced point in time where the breaking change is deployed (how it happened this time).
  - wouldbecouldbe 4y ago
    I don't know any software library that introduces breaking changes as often as kubernetes does. Devops used to be leaning more to stability then devs, it's weird. Kubernetes devops are very expensive so I guess they love being able to spend more time on their tool
    - justinclift 4y ago
      This is sounding like OpenStack all over again. ;)
kobalsky 4y ago
gke is pretty good at that, if there is a forced upgrade coming they will let you know months in advance.
- beebmam 4y ago
  There isn't a single managed vendor of Kubernetes that won't force an upgrade (or shut down your entire cluster if you don't upgrade). It is too costly for these companies to maintain so many old versions of Kubernetes that are not supported. If you want a Kubernetes cluster that never gets forcibly updated or shut down, you should not be using a managed service, period.
  - kobalsky 4y ago
    I may have not expressed it well but what I wanted to say was that GKE communicates very clearly when you will be hit with a forced non-patch upgrade, not that upgrades are undesirable. Running a cluster without updates is a deathwish.
- neuronexmachina 4y ago
  For anyone curious about the actual schedule: https://cloud.google.com/kubernetes-engine/docs/release-schedule#schedule-for-release-channels https://cloud.google.com/kubernetes-engine/docs/release-sche...

figassis 4y ago

Something is always the problem. With a VPS, you don’t usually have to worry about DO being a problem. You pay your bills, your server stays up. Maybe if you don’t update you might get hacked, but killed by provider update is not a failure mode of VPSs. I use k3s on bare metal. I’ve tried to run k8s so many times before and they all failed at some point in ways that didn’t inspire confidence. Mostly etcd became a mess, so this time I’m running k3s with a Postgres datastore that I can actually look at, reason about, backup and independently make HA, with a plus of not having to run arcane commands to manage the cluster that runs my cluster. I once tried nomad because it claimed to be simpler. I stopped when I realized I’d also have to use multiple clusters to run a cluster (nomad+consul). I use k3s because I build apps for multiple clients and I like the flexibility that it gives me in running servers like cattle. My point is that these orchestrators need to start decreasing the enormous amount of risk they add to any project.

tinco 4y ago

I hope you're right, I haven't had time to look at the same warning for 6 months now. There was a hard deadline on it in February and it came and went. The backwards incompatible Kubernetes api updates are a PITA. I know they said "beta", but if you literally have a version field in your manifest format, why ever deprecate a way of configuring something? They could just have operators translate the configs automatically on the fly.

Rantenki 4y ago
>They could just have operators translate the configs automatically on the fly How do they test that across the infinite number of permutations of configurations and deployments of K8S in the field though? It'll work for some people on the happy path, but it's really hard to maintain over time. Worse, it'll break randomly at some point in the future that is hard to predict, instead of at some publicly announced point in time where the breaking change is deployed (how it happened this time).
- wouldbecouldbe 4y ago
  I don't know any software library that introduces breaking changes as often as kubernetes does. Devops used to be leaning more to stability then devs, it's weird. Kubernetes devops are very expensive so I guess they love being able to spend more time on their tool
  - justinclift 4y ago
    This is sounding like OpenStack all over again. ;)

kobalsky 4y ago

gke is pretty good at that, if there is a forced upgrade coming they will let you know months in advance.

beebmam 4y ago
There isn't a single managed vendor of Kubernetes that won't force an upgrade (or shut down your entire cluster if you don't upgrade). It is too costly for these companies to maintain so many old versions of Kubernetes that are not supported. If you want a Kubernetes cluster that never gets forcibly updated or shut down, you should not be using a managed service, period.
- kobalsky 4y ago
  I may have not expressed it well but what I wanted to say was that GKE communicates very clearly when you will be hit with a forced non-patch upgrade, not that upgrades are undesirable. Running a cluster without updates is a deathwish.
neuronexmachina 4y ago
For anyone curious about the actual schedule: https://cloud.google.com/kubernetes-engine/docs/release-schedule#schedule-for-release-channels https://cloud.google.com/kubernetes-engine/docs/release-sche...