Hacker News Reader

Comment by stackskipton | Hacker News Reader

SRE here, my thought is "Sure, Docker Compose is great for production assuming your needs are light and Docker Compose works well for you."

K8s as small time is overkill for sure but make sure you don't fall into this trap. https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

View on HN

Just the other day, someone was asking me if I knew of any options for replicating externaldns for Docker Compose. They didn't want "all the complexity" of running k8s, but wanted the features. This person was absolutely on the way to "building a Kubernetes".

I spun k3s up with a config that I used an LLM to write. It's been almost 2 years. Thing just works for the most part. Even useful on a single node.

Yep, I've got a couple of single node k3s clusters and it just works. It can be a useful way to transition from applications running on their own dedicated servers to running on a true k8s cluster.

What it gets you is a more powerful Docker Compose running on server that you can interact with via kubectl. No SSH, no custom scripts etc. Just kubectl and YAML.

That's mostly my take as well. I'm a big proponent of having separate teams for ops/deployment/sre from app development when you make the jump to k8s though. There's also a few bridge or in-between options for most cloud services as well.

To me, if there's generally fewer than 10 actual active users at any given time and/or you can easily tolerate 30-60m of down time now and then... I'd lean into the simpler option of docker-compose. While I generally think of compose as a dev tool first, it's definitely useful sometimes.

If you go cloud managed (EKS etc), there isn't really much to take care of. I do dev work and even keep a bare metal cluster going as well as a cloud managed one.

Probably needs a real generalist though which maybe doesn't include your average dev.

Reply on news.ycombinator.com