Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…
We have 1 cluster per region (3 regions: Asia, US, EU), multiplied by redundancy clusters = 6 clusters. Then we have test environments, around 20 of them: 20 clusters. Then there are 10s of clusters installed on customers' infra. So 47 clusters isn't really a huge/strange number.
I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
201–210 of 216 posts
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#202-replicates OS services poorly
-OS is likely running on a hypervisor divvying up hardware resources into VPS's
-wastes ram and cpu cycles
-forces kubectl onto everything
-destroys integrity of kernel networking basic principles
-takes advantage of developer ignorance of OS and enhances it
I get it, it's a handy hack, for non production services or oneoff installs, but then its basically just a glorified VM
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#203> DevOps Team Is Happier Than Ever Or course they are. The original value proposition of cloud providers managing your infra (and moreso with k8s) was that you could fire your ops team (now called "DevOps" because the whole idea didn't pan out) and the developers could manage their services directly. In any case, your DevOps team has job security now.
It doesn't take any more competent people to self-host a modern stack, than it does to babysit how a company uses something like Azure. The original value proposition is false, and more and more are realising this.
I think an operations background gives you a strong ability to smell nonsense and insecurity. The DevOps team seems to be people who want to be 'developers' rather than people who care about 'ops'. Yaml slinging without thinking about what the yaml actually means.
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#204Earlier quoted context omitted.
My personal takeaway, when it fails and you can't blame anyone for any reason, blame a tool. You'll get the whole team helping you when replacing the tool and setting up a better solution. If you blame anyone, people will start to be extra cautious and won't take any initiative. But don't overuse it, if you always blame the tool, you'll end up like my ex colleague "Steve" where every failure was Microsoft's fault.
Your ex-colleague may not be factually correct, but I agree with him in spirit.
Steve usually said that Microsoft should ask for a confirmation before deleting anything, even with the "-Force" parameter.
It was Microsoft's fault when the whole test environment, that he spent two days setting up, was deleted with the "-Force" parameter. He said something along the lines of "Microsoft shouldn't let me do this".
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#205Oh boy. Please, please stop using Medium for anything. I have lost count of how many potentially interesting or informative articles are published behind the Medium sign-in wall. At least for me, if you aren't publishing blog articles in public then what's the point of me trying to read them.
It would be nice if there was a common practice of including a link to the alternative version as the first line of a Medium article.
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#206Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…
It's just a matter of time before someone releases an orchestration layer for k8s clusters so the absurd Rube Goldberg machine that is modern devops stacks can grow even more complex.
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#207Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#208If you have 200 YAML files for a single service and 46 clusters I think you're using k8s wrong. And 5 + 3 different monitoring and logging tools could be a symptom of chaos in the organization. k8s, and the go runtime and network stack have been heavily optimized by armies of engineers at Google and big tech, so I am very suspicious of these claims without evidence. Show me the resource usage from k8s component overh…
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#209Earlier quoted context omitted.
Why would those brick everything? You update node one by one and take it slow, so issues will become apparent after upgrade and you have time to solve those - whole point of having clusters comprised of many redundand nodes.
Not sure if this has changed, but there have been companies admitting to simply nuking Kubernetes clusters if they fail, because it does happens. The argument, which I completely believe, is that it's faster to build a brand new cluster than debugging a failed one.
Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever
#210I feel like OP would've been much better off if they just reworked their cluster into something sensible instead of abandoning K8s completely. I've worked on both ECS and K8s, and K8s is much better. All of the problems they listed were poor design decisions, not k8s limitations. - 47 Clusters: This is insane. They ack it in the post, but they could've reworked this. - Multi-cloud: It's now not possible with ECS, but…