4 ms·

trigger warning: bitter jaded ops person working in a real company "[...] users are expected to stay “reasonably up-to-date with versions of Kubernetes they us

trigger warning: bitter jaded ops person working in a real company "[...] users are expected to stay “reasonably up-to-date with versions of Kubernetes they use in production.” [...] the upstream Kubernetes community only aims to support up to three “minor” Kubernetes version at a time. [...] if you deployed a Kubernetes 1.6 soon after it came out last March, you were expected to upgrade to 1.7 within roughly nine months or by the time 1.9 shipped in mid-December." Jesus christ this is so annoying. Businesses don't have a couple hundred billion dollars sitting around to spend on engineers to look at release notes, compare changes, write new features, write new test cases, fix bugs, and push to prod, every 3 months, just to keep existing functionality for orchestrating their containers. We have LTS because businesses (and individuals) don't want to have to do the above. They just want a reliable tool. They want the ability to say that if a bug is found in 3 years, it will be fixed, and they can just keep using the tool. We don't give a crap about "Kubernetes’ domination of the distributed infrastructure world". We don't want to use Kubernetes. We just want an orchestration tool - commodified tooling. We want to stop caring about what we're running. We just want the fucking thing to work, and to not have to jump through hoops for it to work. "Moving Kubernetes Workloads to New Clusters instead of Upgrading" UGH. We only do this for bastardized unholy stupid shit like OpenStack. Not only is this not fun, it takes forever (you try moving 50 different clients off the service they've been using for three years), and you have to have duplicate resources. What the fuck is the point of cloud computing and containers and all this bullshit if I have to have double the infrastructure and juggle how it's all used just to upgrade some fucking software?!??!?! "The Kubernetes-as-a-Service offerings, particularly Google Cloud’s Kubernetes Engine (GKE), are the well-polished bellwethers of what is currently the most stable and production-worthy version of Kubernetes." Oh. We're supposed to pay Google to run it for us. ....I'm just going to use AWS.

kev009 9y ago
Sounds like full employment theorem at work. I haven't kicked the tires on kubernetes yet but I don't really see what all the fuss is about. I liked AMPLab and Mesos but I guess that doesn't have the branding power of big G.
- jacques_chester 9y ago
  I work for Pivotal, which with IBM wrote a container scheduler (Diego) of similar vintage. Nobody has the branding power Google has amongst developers.
- cookiecaper 9y ago
  100% the case. k8s is not a terrible thing and there are good uses for it, but the vast majority of people who are using it don't understand what it's doing, and don't understand that their application is not equipped to handle that type of execution model. Just yesterday I had someone tell me "Kubernetes was like magic and it made everything easy". This is absolutely not the thing a serious/honest Kubernetes user would say. Kubernetes is a big heavy thing, and it's a lot of trouble to maintain it; generally, far more trouble than using sane configuration management on VMs would be (you need sane configuration management in k8s too, so you aren't swapping one complexity for another). We're reaching "MongoDB is web scale" levels of hysteria around Kubernetes. Example of the insanity: my account on HN has been censured for the "tedious" nature in which I would assert that Kubernetes is not a good platform for databases. There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it.
  - jacques_chester 9y ago
    > There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it. Well no, and why would they? Containerisation is one way to crowbar workloads out of VMs and AWS. Since they're coming from behind, their best strategy is to deny everyone else any oxygen by creating an opensource winner. And it worked: Amazon have added EKS to ECS, Azure added AKS to ACI. Google does a lot of good, but they don't sink millions upon millions of dollars into things just for the hell of it.
    - kev009 9y ago
      In general they have been pretty aloof at product marketing and development. Microsoft came in with a weaker product early on and has really been cleaning up with Azure going head to head with Amazon and GCE. G as a whole has always been pretty much the opposite of Apple in terms of fit and finish, and in the past it was no mongo in terms of dev swoon. But I agree with cookiecaper, they have somehow cracked the code for mongo level of installing meme based software architecture on the masses. I would _love_ to understand how that works, for selfish entrepreneurial reasons :)
outworlder 9y ago
I was going to reply to the general point, but I got interested on this: > you try moving 50 different clients off the service they've been using for three years This sounds like a major red flag. Are they on-prem air gapped servers? Do you manage the infrastructure? Because if you do and they aren't, they are not supposed to see it. And if it is automated, what does it matter if there are 50 or 50 thousand clients? The point of the cloud is that the customers don't have to care. And you also shouldn't care about individual servers. Or even clusters. On K8s, it does a lot of really neat stuff that would keep me awake at night otherwise. Oh a K8s worker VM died in AWS. I don't care. There's a machine that's misbehaving. Kill it, another one will come, containers will spawn there. I don't care. Need more container instances, done. Need to deploy a new service? Push the new yaml to the server, done. Upgrade twice a year and you'll be ok, unless your dev team insists on new features.
- peterwwillis 9y ago
  > they are not supposed to see it There's a whole lot of things that are not supposed to happen in the tech world, that happen all the time. Most people do not run brand new stateless microservices in K8s. They run stateful apps on VMs in three year old badly configured OpenStack clusters. For what it's worth, moving the client traffic itself is seamless and totally fine. But first you have to get them to stop hard-coding the names of region and zone specific load balancers into their apps. You switch them over... traffic falls over... and it's your fault. Hence, big moves are coordinated with clients, not to mention feature tested, and then tested by sending some real traffic to the new cluster, before you shift all the traffic. The cloud is not magic, and if you treat it that way, it will bite you.
maherbeg 9y ago
I also wouldn't be surprised if an external vendor will build LTS releases for a fee. That's a pretty common and successful model that would solve this problem easily.

kev009 9y ago

Sounds like full employment theorem at work. I haven't kicked the tires on kubernetes yet but I don't really see what all the fuss is about. I liked AMPLab and Mesos but I guess that doesn't have the branding power of big G.

jacques_chester 9y ago
I work for Pivotal, which with IBM wrote a container scheduler (Diego) of similar vintage. Nobody has the branding power Google has amongst developers.
cookiecaper 9y ago
100% the case. k8s is not a terrible thing and there are good uses for it, but the vast majority of people who are using it don't understand what it's doing, and don't understand that their application is not equipped to handle that type of execution model. Just yesterday I had someone tell me "Kubernetes was like magic and it made everything easy". This is absolutely not the thing a serious/honest Kubernetes user would say. Kubernetes is a big heavy thing, and it's a lot of trouble to maintain it; generally, far more trouble than using sane configuration management on VMs would be (you need sane configuration management in k8s too, so you aren't swapping one complexity for another). We're reaching "MongoDB is web scale" levels of hysteria around Kubernetes. Example of the insanity: my account on HN has been censured for the "tedious" nature in which I would assert that Kubernetes is not a good platform for databases. There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it.
- jacques_chester 9y ago
  > There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it. Well no, and why would they? Containerisation is one way to crowbar workloads out of VMs and AWS. Since they're coming from behind, their best strategy is to deny everyone else any oxygen by creating an opensource winner. And it worked: Amazon have added EKS to ECS, Azure added AKS to ACI. Google does a lot of good, but they don't sink millions upon millions of dollars into things just for the hell of it.
  - kev009 9y ago
    In general they have been pretty aloof at product marketing and development. Microsoft came in with a weaker product early on and has really been cleaning up with Azure going head to head with Amazon and GCE. G as a whole has always been pretty much the opposite of Apple in terms of fit and finish, and in the past it was no mongo in terms of dev swoon. But I agree with cookiecaper, they have somehow cracked the code for mongo level of installing meme based software architecture on the masses. I would _love_ to understand how that works, for selfish entrepreneurial reasons :)

outworlder 9y ago

I was going to reply to the general point, but I got interested on this: > you try moving 50 different clients off the service they've been using for three years This sounds like a major red flag. Are they on-prem air gapped servers? Do you manage the infrastructure? Because if you do and they aren't, they are not supposed to see it. And if it is automated, what does it matter if there are 50 or 50 thousand clients? The point of the cloud is that the customers don't have to care. And you also shouldn't care about individual servers. Or even clusters. On K8s, it does a lot of really neat stuff that would keep me awake at night otherwise. Oh a K8s worker VM died in AWS. I don't care. There's a machine that's misbehaving. Kill it, another one will come, containers will spawn there. I don't care. Need more container instances, done. Need to deploy a new service? Push the new yaml to the server, done. Upgrade twice a year and you'll be ok, unless your dev team insists on new features.

peterwwillis 9y ago
> they are not supposed to see it There's a whole lot of things that are not supposed to happen in the tech world, that happen all the time. Most people do not run brand new stateless microservices in K8s. They run stateful apps on VMs in three year old badly configured OpenStack clusters. For what it's worth, moving the client traffic itself is seamless and totally fine. But first you have to get them to stop hard-coding the names of region and zone specific load balancers into their apps. You switch them over... traffic falls over... and it's your fault. Hence, big moves are coordinated with clients, not to mention feature tested, and then tested by sending some real traffic to the new cluster, before you shift all the traffic. The cloud is not magic, and if you treat it that way, it will bite you.

maherbeg 9y ago

I also wouldn't be surprised if an external vendor will build LTS releases for a fee. That's a pretty common and successful model that would solve this problem easily.