Homelab

In the last post of the series on my Kubernetes experiments, I described how to initialize the cluster. In this post, I will go into a bit more detail on what I did once I finally had a cluster set up. Tutorials Never having done anything with Kubernetes before, I started out with a couple of tutorials. The first one was this one. It uses Redis as an example deployment to demonstrate how to use ConfigMaps. This is an interesting topic for me, because one of the things I liked a lot about Nomad was the tight integration with consul-template for config files and environment variables via the template stanza. This stanza allows the user to template config files with inputs taken from other tools. My main use case at the moment is taking secrets from Vault and injecting them into configuration files. Kubernetes does not have this capability out of the box, but I will get into how I will do it further down in this post. The one important piece of knowledge I gained from this tutorial was that when a ConfigMap is used by the pod spec in a deployment manifest, the deployment’s pods are not automatically restarted to take the new configuration into account. This is a bit annoying, to be honest, because it’s something which Nomad does out of the box, at least for certain ways of writing job files. The solution I found for this (while working with pure kubectl at least, using Helm the problem can be solved more elegantly) was to just run kubectl rollout restart deployment <NAME>. ...

After setting up my lab environment in the previous article, I’ve now also set up the Kubernetes cluster itself, with kubeadm as the setup tool and Cilium as the CNI plugin for networking. Here, I will describe why I chose the tools I did, and how I initialized the cluster, as well as how to remove the cluster when necessary. Tools choice Before setting up a cluster, several choices need to be made. The first one in the case of Kubernetes is which distribution to use. ...

So, as I mentioned in my last article, I want to give Kubernetes another try after HashiCorp’s recent license change. This also gives me a chance to put the lab back in Homelab, as it has mostly been a Homeprod environment - not much experimentation going on there, just slow, intentional incremental changes here and there. But my Homeprod env is not really suited for housing a Kubernetes cluster. It mostly consists of Raspberry Pis. Don’t get me wrong, it is serving me well - but running two parallel clusters with two different orchestrators on the same HW is probably not a good idea. 😉 ...

Basically my entire Homelab is build upon HashiCorp’s products. On August 10th, HashiCorp announced that they would switch all of their products to the BSL, the Business Source License, where they had been licensed under the Mozilla Public License before. From my (rather rudimentary!) understanding, the license basically says that all “non-production” use is perfectly fine. I’m pretty confident that that covers all of my own personal usage. But as it was pointed out to me today, that formulation also creates a lot of uncertainty for commercial entities of all kinds. ...

I started my Fediverse journey a little over a year ago, with my account creation date being August 3rd, 2022. I was initially drawn to the Fediverse due to the simple fact that this was social media I could host myself. Neat, right? And I want to reflect a little bit on how it’s going. So let’s start with my social media usage in the past, so you can properly classify where the following comments are coming from. ...