All the maintenance you put towards getting things running right now will be maintenance you put towards making sure your cluster is doing what you need and wan

All the maintenance you put towards getting things running right now will be maintenance you put towards making sure your cluster is doing what you need and want. If you start having more servers, a k8s cluster can do something like automatically transfer workloads when one machine has an issue for example, or dynamically allocating storage (even cloud) when needed, or allowing you to issue a single command to spin up more instance of whatever task you'd want to run more in parallel, or updating a version in a config file and letting the cluster do the job of stopping/updating/restarting things. But what you also have to do is ensure the underlying networking between machines works, all versions of the binaries on all the machines of the cluster are in close agreement with each others, encryption of data via certificates and CAs is satisfactory, and your master(s) might require different maintenance from the workers - but you'll end up reading the docs to know how to roll updates step by step. In your use case I would stick with a smart use of docker-composes, perhaps just centralized in a private repo, with cron jobs on top. If you buy/rent a couple machines of any kind (from raspberry pis to cloud instances) to put on your network and run things for you, then a cluster becomes increasingly interesting as the amount of tasks needed/wanted and amount of computing available grows. My context: I have some limited experience with work (including some scary "abstractions" on top of K8s & Helm) and a recent CKA (certified kubernetes administrator hands-on certification) from LinuxFoundation.