Hacker News Reader

Comment by cjk | Hacker News Reader

I wish there were more people saying stuff like this these days. Reaching for k8s right out of the gate is so rarely the necessary approach.

View on HN

In the current ecosystem even for a single server I would use K8S via something like minikube. You get for free: operators, observability, a standard API (so you can use helm and such), ...

One of the problems is managing a server is a giant pain in the ass. Say you run your Java app on the said H3 instance, keeping it “clean” requires tooling like ansible or chef. Docker is another option and containers are a nice abstraction. You can still run a single container on this giant instance.

But then you have to update the container, and you need a script to do it. Then you need to roll something back, maybe automatically. Maybe you want a load balancer in front of your server to do TLS termination, and at this point you’d benefit from just using k8s (or ecs or google cloud run)

For a single server I’d rather have one config management system - Chef/Ansible/… - and just have that set up docker & nginx, rather than have config management set up Kubernetes, and then also need to write Kubernetes manifest YAML files in addition to my config management thingies.

On my home server I use Chef. I have a recipe for each service that sets up a docker container plus an NGINX config that does the TLS and port mapping stuff. To handle container updates I run Watchtower (https://containrrr.dev/watchtower/) which pulls and then restarts my containers when I send a POST.

Deploys are super easy, just docker build, docker push, curl -h $DEPLOY_TOKEN $DEPLOY_URL.

don’t need anything complicated for rollback, just retag and curl again.

As I said to the other guy - that configuration had to go somewhere, and for a single server it’s not going to be much. I don’t care if it’s 50 lines of bash, or chef, or yaml. I’d guess that the complexity of configuring find and your services is roughly equivalent to the k8s yaml on a simple setup.

It’s a sidestep of complexity IMO.

Personally, I find it loads simpler to use Packer + Terraform, and boot new machines when I have to re-spin the Packer image. Some of the Terraform modules maintained by the cloud providers can reduce the amount of boilerplate you have to write by quite a bit. It’s still non-zero configuration required, but IMO it is easier to understand and manage than piles of YAML.

You only have piles of yaml if you have piles of stuff to use. If you’re just running a single container then it’s not really much yaml at all. The config has to go somewhere, and 50 lines of yaml vs chef vs terraform - I don’t really care.

> Reaching for k8s right out of the gate is so rarely the necessary approach.

Then what is? It seems like a lot of the single server ochestration stuff has all been left to rot.

Reply on news.ycombinator.com