Been running my blog on Kubernetes since 2017[0] and it's been great. Kubernetes is a force multiplier and the natural evolution in deployment methodology. It c

Been running my blog on Kubernetes since 2017[0] and it's been great. Kubernetes is a force multiplier and the natural evolution in deployment methodology. It could be tighter/cleaner but it's extremely good for what it provides, but you have to know why you might need the things it's providing for it to seem worth it. If you'd like to try kubernetes and get to understand it and feel comfortable with it I'd recommend: - Work through kubernetes the hard way[1] (ignore/replace the GCP-specific things, if you don't know enough about what the non-GCP corrolary to a GCP-thing is, that's a bit of knowledge you need to fill) - Set up your own cluster from scratch (no kubeadm, no alternate distros, etc), use the simplest options you can find at first (ex. flannel for CNI) - Set up ingress (NGINX ingress is a good place to start) - Run some simple unsecured but diverse workloads (static sites on NGINX, Wordpress, etc), figure out why you might pick a StatefulSet versus DaemonSet. At this point, use the hostPath/local volumes just to avoid trying to grok volume complexity. - Install a useful cluster tool ("addon") like cert-manager[2] from scratch so you can see Kubernetes manage something you'd normally solve with systemd timers and `certbot` (or your reverse proxy would do for you if you're running caddy or traefik) - Start putting your YAML in source control get familiar with either kustomize, helm, or both (you could also just use Make + envsubst like I did for a while[3]). It's at this point that it should click that all you need to get back to a certain state of your cluster is to get a machine, do basic hardening (ufw, etc), install kubernetes, and run "make" in this repo (excluding things like DNS entries, etc). Now things are probably getting fun, because you can have the distant cousin of immutable infrastructure; repeatable infrastructure. - Tear down your cluster, set it up again with kubeadm (note that kubeadm actually has a file-driven configuration option[3]), run your yaml from source control and confirm that all the workloads you had in place are back up and secured. - (optional) Tear down your cluster, try rebuilding it with k3s[4] or k0s[5] - Start looking around and seeing what your options are and the ecosystem that exists -- digging deeper into the interfaces that make Kubernetes tick, for example volume management (Container Storage Interface) by deploying Rook[6] or OpenEBS[7]. Note that one of the best things that can happen to you during this process is something going wrong. Every time something goes wrong, and you go back to fundamentals to fix it. Being able to reason about kubernetes ad hoc (ex. if DNS is correct but you can't reach port 80/443, what should you check first?) is the key to feeling comfortable with it, and while failures and downtime will happen, you shouldn't feel just complete despair/confusion. Normally, once things are stable kubernetes is quite worry-free. I've made a guide like this before, I'll see if I can find it. [EDIT] Found only one post[8] [0]: https://vadosware.io/post/fresh-dedicated-server-to-single-node-kubernetes-cluster-on-coreos/ https://vadosware.io/post/fresh-dedicated-server-to-single-n... [1]: https://github.com/kelseyhightower/kubernetes-the-hard-way https://github.com/kelseyhightower/kubernetes-the-hard-way [2]: https://github.com/jetstack/cert-manager https://github.com/jetstack/cert-manager [3]: https://www.vadosware.io/post/using-makefiles-and-envsubst-as-an-alternative-to-helm-and-ksonnet/ https://www.vadosware.io/post/using-makefiles-and-envsubst-a... [4]: https://k3s.io/ https://k3s.io/ [5]: https://docs.k0sproject.io https://docs.k0sproject.io [6]: https://rook.io/docs https://rook.io/docs [7]: https://docs.openebs.io/ https://docs.openebs.io/ [8]: https://news.ycombinator.com/item?id=22117684 https://news.ycombinator.com/item?id=22117684