Live data from Hacker News

I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

blog.stackademic.com

81–90 of 216 posts

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#81
What else is out there? I'm running docker swarm and it's extremely hard to make it work with ipv6. I'm running my software on a 1GB RAM cloud instance and I pay 4EUR/month, and k8s requires at least 1GB of RAM.

As of now, it seems like my only alternative is to run k8s on a 2GB of RAM system, so I'm considering moving to Hetzner just to run k3s or k0s.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#82
post #16

How to save 1M off your cloud infra? Start from a 2M bill. That's how I see most of these projects. You create a massively expensive infra because webscale, then 3 years down the road you (or someone else) gets to rebuild it 10x cheaper. You get to write two blog posts, one for using $tech and one for migrating off $tech. A line in the cv and a promotion. But kudos for them for managing to stop the snowball and actua…

I don't think that's necessarily a problem. When starting a new product time to market as well as identifying the user needs feature wise is way more important than being able to scale "Infinitely".

It makes sense to use whatever $tech helps you get an MVP out asap and iterate on it. once you're sure you found gold, then it makes sense to optimize for scale. The only thing I guess one has to worry about when developing something like that, is to make sure good scalability is possible with some tinkering and efforts and not totally impossible.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#83

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.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#84
post #27

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…

There are genuine reasons for running multiple clusters. It helps to sometimes keep stateful (databases generally) workloads on one cluster, have another for stateless workloads etc. Sometimes customers demand complete isolation so they get their own cluster (although somehow its ok that the nodes are still VMs that are probably running on shared nodes… these requirements can be arbitrary sometimes).

Yes, a few, maybe even 10, 12, but 47? It's also a prime number, so it's not something like running each thing three times for dev, stage and prod.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#85
post #73

Earlier quoted context omitted.

We ran only two (very small) clusters for some time in the past and even then it introduced some unnecessary overhead on the ops side and some headaches on the dev side. Maybe they were just growing pains, but if I have to run Kubernetes again I will definitely opt for a single large cluster. After all Kubernetes provides all the primitives you need to enforce separation. You wouldn't create separate VMWare productio…

You need a separate cluster for production because there are operations you'd do your staging/QA environments that might accidentally knock out your cluster, I did that once and it was not fun. I completely agree with keeping everything as simple as possible though. No extra clusters if not absolutely necessary, and also no extra namespaces if not absolutely necessary. The thing with Kubernetes is that it was designe…

Do you mind sharing what these operations were? I can think of a few things that may very well brick your control plane. But at the very least existing workloads continue to function in this case as far as I know. Same with e.g. misconfigured network policies. Those might cause downtimes, but at least you can roll them back easily. This was some time ago though. There may be more footguns now. Curious to know how you bricked your cluster, if you don't mind.

I agree that k8s offers many features that most users probably don't need and may not even know of. I found that I liked k8s best when we used only a few, stable features (only daemonsets and deployments for workloads, no statefulsets) and simple helm charts. Although we could have probably ditched helm altogether.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#86
post #72
post #59

Earlier quoted context omitted.

Kubernetes upgrades? Don't those risk bricking everything with just 1 environment?

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.

I think it depends on the definition of "bricking the cluster". When you start to upgrade your control plane, your control plane pods restart one after one, and not only those on the specific control plane node. So at this point your control plane might not respond anymore if you happen to run into a bug or some other issue. You might call it "bricking the cluster", since it is not possible to interact with the control plane for some time. Personally I would not call it "bricked", since your production workloads on worker nodes continue to function.

Edit: And even when you "brick" it and cannot roll back, there is still a way to bring your control plane back by using an etcd backup, right?

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#87

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…

Don’t know about the writer of the article, but there are some legit reasons to use multiple K8s clusters. Single-tenant environments, segregation of resources into different cloud accounts, redundancy (although there are probably lots of ways to do most of this within a single cluster), 46 different developer / QA / CI clusters, etc.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#88
post #81

What else is out there? I'm running docker swarm and it's extremely hard to make it work with ipv6. I'm running my software on a 1GB RAM cloud instance and I pay 4EUR/month, and k8s requires at least 1GB of RAM. As of now, it seems like my only alternative is to run k8s on a 2GB of RAM system, so I'm considering moving to Hetzner just to run k3s or k0s.

Are you not using docker swarm behind a reverse proxy?

ie nginx has the public facing ipv4 & ipv6 address(es), with docker swarm behind that communicating to the nginx proxies over ipv4

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#89

Earlier quoted context omitted.

> "Create an account to read the full story." Why is this required?

They are also misleading the users with that message. I signed up, but now I got a message that I have to upgrade to a paid account... If they had told me that from the start, I would not bother with creating an account at all. The message implies that a free account would be enough

This is why I always sign-up for something first time with fake data and a throw-away email address (I have a catch-all sub-domian, that is no longer off my main domain, for that). If it turns out the site is something I might care to return to I might then sign up with real details, or edit the initial account, if not then the email address given to them gets forwarded to /dev/null for when the inevitable spam starts arriving. I'm thinking of seeing if the wildcarding/catchall can be applied at the subdomain level, so I can fully null-route dead addresses in DNS and not even have connection attempts related to the spam.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#90
I've looked into K8s some years back and found so many new concepts that I thought: is our team big enough for so much "new".

Then I read someone saying that K8s should never be used for teams Our team is smaller than 20FTE, so we use AWS/Fargate now. Works like a charm.

Post reply on HN