Comment by lakomen | Hacker News Reader

Comment by lakomen | Hacker News Reader

k8s is, and I wrote it countless times, a huge waste of resources.

The whole event driven distributed design is.

There aren't many use cases that require more than 5k concurrent clients and the number is even higher without the HTTP overhead (a single bare metal server can handle with the proper language).

For most companies it's a waste of money.

k8s is hype tech designed to drive business to public cloud providers, because of its complexity and high hardware demands. 9 bare metal servers minimum.

And then you have those pods, which are collections of services (e.g. postgres + api server + some cache). But in the case of postgres, why wouldn't you have a dedicated cluster instead of multiple, isolated instances as it is the case with k8s?

I know, now the EDA faction chimes in with their dogma. Again most cases don't require even 5k concurrent clients. And most projects never will grow to the point of that many concurrent clients.

Addendum: And then I read the who is hiring thread and it's all k8s k8s k8s... frustrating

> And then you have those pods, which are collections of services (e.g. postgres + api server + some cache).

Pods are not intended to bundle those 3 services. Typically one would use higher level abstractions (Deployment for the API, StatefulSet for the database), each composed of multiple Pods that should be scheduled on different physical machines.

It’s no wonder you’ve had a bad experience trying to use it the way you describe. Following the intended patterns provides a standard way to achieve rolling updates, horizontal autoscaling, and a ton of other functionality that used to be bespoke code at each organization. The old way was often buggy, and onboarding new engineers took much longer.

Maybe their terminology was wrong, but what about this point:

> But in the case of postgres, why wouldn't you have a dedicated cluster

Does k8s not push you to mix postgres pods in the same host as your API pods? Unless you go out of your way to handicap it.

I understand the appeal of applying the k8s (or swarm, or nomad) model to stateless API containers, but mixing in stateful db containers and pretending they're all equivalent makes less sense to me.

Many applications don't need multiple physical machines worth of database.

Persistent storage has been a solved problem, especially when using a managed Kubernetes service. What's the problem with running stateful workloads on a cluster?

What's wrong is that it adds extra layers of abstraction just to satisfy k8s. Extra layers aren't free.

I'm not an idiot so don't treat me like one. I know what I'm talking about, unlike you apparently.

You can have all that without k8s. k8s doesn't equal auto scaling, "rolling updates".

You are a booksmart idiot.

https://kubernetes.io/docs/concepts/workloads/pods/

This guy, seriously.

Completely ignores everything I wrote and starts bullshitting.

Where on that page is it recommended to bundle your entire infrastructure stack into a single pod?

My intent wasn’t to criticize you, but apparently I stuck a nerve…

Of course you can have all that without k8s. I’ve been operating cloud infra for over a decade, and I used to roll my own solutions to implement that functionality, so I’m quite familiar with that approach. Embracing kubernetes has made life much easier. I do read a lot, but my opinion is based on operating production systems. Whether you like it or not, k8s has become the defacto standard interface for distributed systems.

High level programming languages and libraries provide useful layers of abstraction in their own domains. Do you also reject those, and use assembly language for everything?

k8s is a complex solution for complex problems. You don't need k8s to host landing or personal blog type of service.

Once you move to a type of project with complex demands around deployments, log management, failover management, secrets, environments, resource isolation, etc., then building something to solve this set of problems over and over again is very expensive when off-the-shelf battle-tested solution is available.

What about using docker swarm or even a single node docker swarm cluster? I think that could be a viable alternative for small stuff.

The thing is, k8s has a lot of mindshare. It's entirely easier to go and find some pertinent issue with your k8s set-up through a simple search, whereas e.g. nomad and swarm have much less mindshare.

You don't have to go full complexity with k8s. You can just use a managed k8s provider and ship a simple deployment with an anti-affinity policy to distribute across VMs on creation. Sure, there are other solutions [and this one is likely to not be the cheapest], but they're all vendor locked--k8s is about as close to a cloud agnostic compute as we're likely to get.

I enjoy docker swarm for small hobby projects. It's simple and easy to maintain if you want to benefit from container apps and configuration.

Once your service grows, you'll notice some rough edges around the docker swarm. When you start having dedicated SRE/DevOps roles, moving from heroku/swarm to k8s will make sense.

The arrogance of you.

You can do more on a single server than hosting "landing pages" or "personal blog".

I host seemingly complex projects with simple methods, without needing any complex k8s crap.

That's what you people aren't getting.

You're so full into the complexity that you don't see the simple solution as something worthwhile.

WHAT about k8s is more battle tested than decades of doing the simple and efficient on a 1-3 servers?

You're brainwashed. Possibly even a shill of one of those expensive cloud providers.

Reply on news.ycombinator.com