awesome-home-kubernetes VS nerve

Also check out the awesome kubernetes@home repo where many homelabbers share their configs.

Sorry I'm not familiar with this. Are you referring to this?

https://github.com/k8s-at-home/awesome-home-kubernetes https://github.com/k8s-at-home/template-cluster-k3s

To see it in action be sure to check out my repository or the many others here.

Make it usable and link to the best place with k3s in action: https://github.com/k8s-at-home/awesome-home-kubernetes

Nice but I suggest going to https://github.com/k8s-at-home/awesome-home-kubernetes and learn from the best at this topic ;)

Check out Flux V2. It syncs a git repo with your cluster, allowing you to define your infrastructure as code. It will keep your cluster synced with your repo and detect changes. A number of example repos are Here and onedr0p did a example repo here There's many options for structuring folder, I'd recommend you have a look at a few repos and pick one you like. The linked template is a good start, as it helps avoid dependency hell with a crd folder that starts before the YAML that needs the crd defined. Many people on the awesome list also run ansible for full infrastructure as code. I spent a lot of time perfecting my setup to go from blank Ubuntu VM to my cluster with a few keystrokes. Running it in git also helps you be able to use things like renovate bot to keep versions up to date. As for namespaces, everyone had their own method, but about using kube-system. Also, keep a eye out for services that refuse to have their name space changed.

I run GKE for some small apps. I also use AWS S3 hosting for my personal blog. The cost differences are... non trivial to the point of a bad joke, if we were comparing ability to reliably ship plaintext over the wire. But I'm not. I host a database and webapps on the k8s cluster, without adding extra EC2 nodes, RDS costs, or wrestling with AWS Lambda limitations.

I can also confidently say that having something approximating a stable web app demands doing a lot of serious thinking, and "a single server running Apache on Digital Ocean" does not cover that case sufficiently. You need to tolerate failure, failover, load balancing, bin-packing, etc. I used to run a small autoscaling group on EC2 for my own systems; the dang thing would fail to come up on one node very frequently and so a number of the queries would fail. I eventually burnt it to the ground and redid it. I've never had that hassle in k8s. Its designed to succeed, in a way the "box of parts" approach doesn't.

Boxes of parts are useful. For a complexity-sensitive & thoughtful infrastructure engineer, having something like the old Synapse/Nerve[1] system with your apps distributed across some 5-20 machines with a monitor lease to spawn new ones on failure would probably approximate Kubernetes for a few years, until you have to do something fancypants. You've still reimplemented part of Kubernetes, though... The other angle is, boxes of parts can go in wildly weird directions.... if you need it.

Looking at some infrastructure these days professionally, the question is - when do we move to Kubernetes. It's not interesting or useful to the company to be maintaining our own thing or own strange path. The only questions are around the path - how much rework needs to happen and how much building in k8s needs to happen to get there.

GKE is a very good starting point for k8s. Strong recommend.

https://github.com/airbnb/nerve