It's honestly not even that hard to run a full blown k8s cluster, I've been doing it for years, and even though I've made my share of mistakes along the way and downtime, I'm no longer scared of the k8s complexity boogeyman. Learn how it works from first principles, and the magic will disappear -- errors can still be daunting, but if you follow the concepts something normally jumps out at you. More than anything what gets people is the hypetrain and quickly moving libraries that just don't follow the "don't break user space" mantra these days.
k8s is complex, but the complexity is for the most part essential. Just about every kubernetes concept maps to a thing you'd have to handle yourself if you ran one or more robust personal servers. It is a simple control loop, that you can run on only one machine -- one bit to check what should be running (etcd + apiserver), one bit to run the things (kubelet), and some bits to make sure they stay running (controller-manager and the other controllers).
It is certainly more complex than Dokku[0] or Caprover[1] but that's because those are very focused on running applications -- Kubernetes aims to run more things, and for more use cases, but you don't have to know about all the use cases, just the ones that matter to you.
All that said, I've been working on an orchestrator that simpler to operate than kubernetes, because I think kubernetes stumbled upon it's most powerful feature (operators) too late, and the answer to simplicity might actually be breaking kubernetes apart even more.
Thanks for asking -- most of the ideas are in my head (I have a ton of long, scattered notes in Joplin), but I've started to transfer them to a repo. I'm starting with a repo of RFCs, which are really just me getting all my thoughts out there so they can be critiqued:
I noted that I wanted it to be developed in the open and fretted a bit about whether I should finish the initial design first or not, but figured I should just put it out there, so people can look at it and comment if they want.
The PoC to make sure this all works feels like a weekend of work (just because of how simple it is), but the upfront design is probably the hardest part. As you can see the design is so simple that the real work is defining the interfaces and leaving room for flexibility/protocol evolution.
k8s is complex, but the complexity is for the most part essential. Just about every kubernetes concept maps to a thing you'd have to handle yourself if you ran one or more robust personal servers. It is a simple control loop, that you can run on only one machine -- one bit to check what should be running (etcd + apiserver), one bit to run the things (kubelet), and some bits to make sure they stay running (controller-manager and the other controllers).
It is certainly more complex than Dokku[0] or Caprover[1] but that's because those are very focused on running applications -- Kubernetes aims to run more things, and for more use cases, but you don't have to know about all the use cases, just the ones that matter to you.
All that said, I've been working on an orchestrator that simpler to operate than kubernetes, because I think kubernetes stumbled upon it's most powerful feature (operators) too late, and the answer to simplicity might actually be breaking kubernetes apart even more.
[0]: https://github.com/dokku/dokku
[1]: https://github.com/CapRover/CapRover