[ralmeida]

Exactly! Other non-scalability concerns they address (specifically talking about Kubernetes here) is a primitive amount of monitoring/observability; no-downtime updates (rolling updates); liveness/readiness probes; primitive service discovery and load balancing; resiliency to any one single host failing (even if the total compute power could easily fit into a single bigger server).

[dsr_]

Which of these are things you want on your house server? That's what the article author is writing about, and what I am writing about.

I do not need an octopus conducting a herd of elephants.

[gavinray]

I can agree that the idea of reaching for Kubernetes to set up a bunch of services on a home server sounds a bit absurd.

"How did we get here?"

I'm not an inexperienced codemonkey by any means of the term, but I am a shitty Sysadmin. And despite being a Linux user from early teens, I'm not a greybeard.

As sorry a state as it may sound, I have more faith in my ability to reliably run and maintain a dozen containers in k8s than a dozen standard, manually installed apps + processes managed by systemd.

Whether this is a good thing or a bad thing you can likely find solid arguments both ways for.

[henryfjordan]

You only have to learn 1 interface (albeit a complicated one) to use Docker/k8s compared with 1 interface per service to run them manually.

[klodolph]

Hm, these days I feel like I only have to learn systemd. Reload config? View logs? Watchdog? Namespaces? It’s all systemd. If you are running on one machine, what does Docker/k8s give you that you do not already have?

[nineteen999]

> If you are running on one machine, what does Docker/k8s give you that you do not already have?

That feeling that you are part of a special, futuristic club.

[vineyardmike]

Nothing, but its pretty common to have the home server plus a desktop/laptop where you do most of the work (even for home server), that may not be linux - in which case containers are the easiest way

[p_l]

I recently ended up setting up "classic" server again after a significant time keeping mostly containerized infrastructure on k8s.

Never again, the amount of things that are simply harder in comparison is staggering.

[Scramblejams]

Sorry to sound pedantic, but what was harder? Containerized infra or a classic server? I assume the former but wanted to be sure.

[p_l]

"Classic" approach turned out to be maddeningly harder.

Everything, even inside single "application", going slightly off the reservation. Services that would die in stupid ways. Painful configuration that would have been abstracted out were I running containers on k8s (some benefits might be realized with Docker compose, but docker on its own is much more brittle than k8s).

So much SSH-ing to a node to tweak things. apt-get fscking the server. Etc.

Oh, and logging being shitshow.

[arcticfox]

To me it sounds like the latter, a classic server, which I agree... After getting comfortable with containerized deployment, "classic" servers are a huge pain

[ralmeida]

Fair enough, my point was more about using k8s to deploy applications rather than “house server” stuff, where it’s indeed unneeded more often than not.

[threentaway]

Having zero downtime updates is quite nice. For example, I can set FluxCD to pin to a feature release of Nextcloud, and it will automatically apply any patch updates available. Because of the zero downtime updates, this can happen at any time and I won't have any issues, even if I'm actively using Nextcloud as it's happening.