I think his argument is that the functionality is unnecessary. You don’t need dynamic service scaling because your single-instance service has such high capacity to begin with.

I guess it’s all about knowing when to re-engineer the solution for scale. And the answer is rarely ”up front”.

▲

ianpurton 12 hours ago | parent [-]

Dynamic scaling is not really even available on a single node kubernetes.

I was thinking more of

Running multiple websites. i.e. 1 application per namespace. Tooling i.e. k9s for looking at logs etc. Upgrading applications etc.

▲

sgarland 10 hours ago | parent | next [-]

Namespaces exist in Linux [0], they weren’t invented by K8s.

You can view application logs with anything that can read a text file, or journalctl if your distro is using that.

There are many methods of performing application upgrades with minimal downtime.

0: https://www.man7.org/linux/man-pages/man7/namespaces.7.html

▲

ianpurton 8 hours ago | parent [-]

Thats true. The reason I like k8s is once you've gone up the learning curve you can apply that knowledge to cloud deployments, on prem, or in this case VPS.

The authors stack left me thinking about how will he re-start the app if it crashes, versioning, containers, infra as code.

I've seen these articles before... the Ruby on Rails guys had the same idea and built https://kamal-deploy.org/

Which starts to look more and more like K3s as time goes on.

	▲	Jolter 7 hours ago \| parent [-]
		I’m thinking even simple containers have automatic restarts. I wouldn’t deploy to prod using ”docker start” but I wouldn’t look askance at someone using “docker compose” for that purpose.

▲

Jolter 7 hours ago | parent | prev [-]

Namespacing is great; look at how Notepad++ was hacked. They were sharing a non-namespaced deployment with other applications, IIRC.