>
Complex solutions exists for complex needs. If you just need to...Personally, to me, this sounds like madness.
Deciding you need to custom tailor and brew up a specific solution that exactly matches each use case begets endless complexity. Constantly negotiating a position & changing approaches begets endless complexity.
And the complexity needle moves over time, such that your initial assumptions often don't stand. Getting something running usually isn't too hard. But creeping demands of observability, monitoring, rotating certs, backups, and other concerns are going to start getting tacked on. If you only ever do one thing, and there aren't many of ya'll & never will be, and very few newcomers will ever join, maybe maybe maybe you find a win today by doing less, by hand picking your options & getting in there & cobbling your stack of tools together. Convincing yourself to start small, to avoid "complex" Kubernetes to do less, is in most cases though going to backfire even for a single piece of software, as situations evolve.
There is such a fear that Kubernetes is complex, but it just feels like so many are missing the point, are resisting the standards & practices that erulabs' spoke to.
But man, it is so not complex to prop up a big k3s node & push some containers at it. And anyone whose spent more than 1 hours with kube will be able to look around, see what's running on the node, see how everything works; you won't have to explain what you did, it'll be obvious. And they'll be able to keep going. And you'll be able to keep encorporating concerns & platform & new apps in. And those skills - mastering that complexity - will transfer to every other thing you want to do, will scale way up and way down.
(I do think systemd offers a good number of similar advantages of replicatability, consistency, paved-roadness, and is pretty solid an option, but involves more finding-your-practice than kube)