This is such a great write-up. I hope we continue to evolve the modern ops set-up on the metal, make it easy for folks to onboard into something that scales both big & high, and small & low. This is, imo, enormously good tech to learn, and I feel like many people are wasting their time learning "things that work for them" or that "aren't as complex" when those personal choices & investments will, in all due chance, not pay off elsewhere, will not be things other people are as likely to know or use or enjoy. And k3s is so easy to use, works so well, that I think many folks kind of cheat themselves out of a better experience when they pick something a little more legacy, like Docker-compose.

Also noteably that this is just a first step, & we can get better & better at creating a wider system of services for the personal server from Kubernetes. For example I use the zalando postgres-operator, which lets me just ask for/apply a kubernetes object, and presto-chango, i have a postgres database with as many replicated instances as I want. The author here similarly enjoys having Let's Encrypt being ambient available. Managing more and more systems within Kubernetes will continue to scale the operational network effect of choosing tech like Kubernetes, tech that doesn't just run containers, but is an overaching cloud. Kubernetes is Desired State Management, a repository for all of your (small) cloud's state.

I'd consider maybe replacing some of the hand-made Wireguard work done here with Kilo[1], which can either run as a Container Network Interface (CNI) plugin or can wrap your existing Kubernetes networking CNI provider (by default K3s uses Flannel). This will automate the process nicely, let you manage things like peers in Kubernetes easily. When the author connected the RPi to their existing cluster, that's exactly the sort of multi-cloud topology that Kilo is there to help you run & manage, and from inside of Kubernetes itself! Kilo rocks.

Also worth noting that some of the latter half of this write-up is optional. Switching K3's own ingress out for nginx is the authors opinion, for example. You may/may not need a mail server. The write-up is pretty long; I think it's worth highlighting that the core of what's happening here, what others would need to do, is pretty short.

I do enjoy that the author started the steps by running gpg & sops, to make keys to secure this all. This is pretty rigorous. It's good to see! I don't think all operators have to do this, but it showed that the author was taking it fairly seriously.

For reference, I run a 3 node K3s cluster at home, a separate single K3s instance, and am planning on trying to convert my laptops & workstations over so that operationally I get the same kind of great observability & metrics & managability on them that I enjoy on the cluster. I'd like to cloud-nativize more of of my day to day computing experience, for consistency sake, & because I think uplifting many of the local things on my machine into pieces of a larger Cloud body of state will give me more flexibility & capabilities that I can enjoy playing with. I look forward to becoming less machine-centric, and more cross-machine cloud-centric.

[1] https://github.com/squat/kilo