I wouldn't go so far as "no valid reason", but yeah, it is always fun to come on HN and see how everyone using k8s is just doing "resume-driven development" and mindless automatons manipulated by "marketing." I always find it amusing because a lot of these takes seem like thy are at least 5 years out of date. If you are on any one of the major cloud vendors, setting up a k8s cluster is almost trivial at this point. And that comes with a fully-managed control plane and a vibrant ecosystem of drop-in solutions for common deployment patterns.

Do you always need k8s? Of course not, but it really is getting to the point where all but the most trivial of deployments could benefit from running on k8s. Are there other ways to do it? Sure, but the complexity of using k8s has been sanded down through widespread adoption and really nice tooling.

Preface this with I don't hate K8s. I see it as a solution and something to be used when the situation calls for it. I've used it quite a bit from directly interacting with it using Go and it's Go modules, using it's REST API, via kubectl, and via those that provide front-ends for it (Rancher).

I see it as all about use-case, staffing, and what kind of instance you are using. Cloud-based? A-lot more freedom in being able to just deploying a cluster and not worry about much, on-prem based? Well dang now you've opened up having to be the one to update those nodes yourself - hope that you are a systems admin as well and have the time to perform said updates.

Situation A - I'd like to introduce you to Docker Swarm.

Secret management - sure K8s can do it, but I'm almost certain your organization as well as mine has accepted a vault of some sort that is not in K8s for end users and services to use. Now you just have to write your applications to use this.

Network policies - while K8s can do this, I don't know if this is the strongest argument to use K8s or just a nice cherry on top. It feels like just a shift in responsibility or adding more granularity from your network security team.

When does the situation call for it (in my opinion)? Your company has embraced the methodology of work with staffing for it and you have more than a handful of apps on more than a handful of nodes.

> I love how HN hates k8s for no valid reason.

There's lots of valid reasons to not use K8s. I don't hate it. What I strongly disagree with is its use-by-default (not unlike how software is now Microservices-by-default.)

K8s offers lots of functionality (that most folks don't require) in exchange for operational complexity. If you're Google, Microsoft, or a huge organization that can truly afford a DevOps team, then more power to you. But for most small/medium sized businesses they're simply not getting the ROI for the resources they're putting into it. We don't bat an eyelash at those costs because "that's just how you deploy apps in the cloud" today. Same goes for Microservices. Monoliths aren't perfect, but at some places that blindly pray at the altar of Microservices wind up building distributed monoliths, adding complexity and friction that is simply not worth their cost.

Unpopular opinion: K8s and Microservices have hurt more than helped our industry at companies where scaling is not a huge factor (99% of companies.)

We use both, but I much prefer docker-compose, because systemd scatters deployment files in system directories, which makes them a bit of a pain to find and backup. Not sure if we're doing it wrong.

docker-compose is just one folder per service, much more practical.

The equation gets a bit different the further away you get from spending bonanza of silly valley