Kubeexp

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. 😉 ...