In a DNS zone that I had laying around, I’ve come with the following scheme to have a working DNS with systemk. Note this does not deal with the control plane, those are routed via tailscale and I’m using IP addresses there. If naming is required here, it can be fitted in the scheme as well. Using example.org as the domain here. Scheme An m “subdomain” (it’s not delegated) holds all the names and IP address of the machines of interest.
Due to a previous job I’m calling nodes, “machines”, also because this is about systemk, it’s more likely you are actually using a real machine. So I’ll keep on using “machines” in this post. First up: I needed an easy way to build packages of the software I’m using. For this I’ve setup a small CI using GitHub workflows that builds Debian packages for me: https://github.com/miekg/debian. (A Debian package repository would even be better, so I can more easily do upgrades).
The everything is a object in Kubernetes is a very nice abstraction. The ability to influence it with just kubectl makes for only one control plane (to learn). The networking, ingress, discovery, installation, etc. are all not that great. So I’m pondering marrying the things I love: have a plain Debian system, “normal” networking (no overlay/underlay/whatever), Debian packages, etc. And controlling it all via kubectl. This should include a sane installation and allow for rollbacks.
A four week yak shaving expedition