Skip to content

server

Migrating Kubernetes volumes to Longhorn

Migrating NFS volumes to the NFS CSI driver was an easy step forward preparing the single-node Kubernetes cluster to be upgraded to an Active-Active High Availability cluster. The next step in that direction is to migrate volumes currently implemented (the lazy way) with hostPath pointed to local NVMe SSD storage to a distributed file system, while still leveraging the SSDs speed as high-availability distributed volumes replicated across every node's local NVMe SSDs.

Migrating NFS volumes to the NFS CSI driver for Kubernetes

NFS volumes have been mounted the lazy way as hostPath volumes, with the entire NFS volume being mounted by the host OS. While this works well enough in a single-node cluster, it wouldn't work well in a multi-node cluster and is just not the proper way to mount NFs volumes in Kubernetes.

For a better, safer and more efficient setup, NFS volumes will now be mounted using the NFS CSI driver for Kubernetes.

Upgrading single-node Kubernetes cluster on Ubuntu Studio 24.04 (octavo)

Upgrading the single-node kubernetes cluster on lexicon went smoothly, so it's time to repeat the process on octavo and alfred, especially since the current version (1.32) will be the next one up to go End Of Life in Feb 28, 2026 and a preemptive Kubernetes Certificate Check reveals certificates are due to expire by Feb 22 on alfred and April 26 on octavo.

Checking deployments before upgrading kubeadm clusters again found results mostly reassuring for version 1.34.

Monitoring a Kubernetes cluster for vulnerabilities

Replacing Ingress-NGINX with Pomerium, prompted by the upcoming retirement in March 2026 of Ingress-NGINX controller, was a stark reminder the importance of keeping deployments updated and staying abrest of security issues, vulnerabilities and deprecations.

Manually monitoring each application's repository for new releases, to then update each deployment manually, work well for a few deployments but does not scale well to dozens of deployments. The process should be automated to automatically update deployments, at last those with a good track record of hassle-free updates, so that manual updates are needed only for those prone to requiring more attention, intermediate backups, etc.

Replacing Ingress-NGINX with Pomerium

The community Ingress-NGINX controller is scheduled for retirement in March 2026, so the time comes near to replace it with either a compatible Ingress-NGINX controller or migrate to the new Gateway API. Given the relatively short migration timeline, the former promises the least friction and complexity for self-hosted, single-node clusters.

The clusters (octavo and alfred) are currently running Kubernetes version 1.32 which is will be the next one up to go End Of Life in Feb 28, 2026. Updating the cluster to Kubernetes version 1.34 would first require updating Ingress-NGINX to version 1.14 according to its Supported Versions table.

Instead, it is possible to replace Ingress-NGINX entirely with Pomerium, which serves as a direct, secure-by-default alternative that combines standard reverse proxy functionality with integrated Zero Trust identity verification.

Raspberry Pi 5 setup for a buddying coder

As a certain season approaches, I embarked in a little side quest: to setup a Raspberry Pi 5 for a good bro who is learning to code and wants to learn more about Linux as well. Since his goal is learning to code rather than (I hope) getting lost down the infinite rabbit holes of tinkering with the OS and tools, I set this up so he doesn't have to, but otherwise left it basic and uncomplicated.

Home Assistant on Kubernetes on Raspberry Pi 5 (Alfred)

That old house with aging electrical wiring, where last winter we needed Continuous Monitoring for TP-Link Tapo devices to keep power consumption in check at all times, could do with a more versatile and capable setup, to at least partially automate the juggling involved in keeping power consumption within the contracted capacity.

Home Assistant should be a good way to scale this up, but what that old house needs in the first place is a 24x7 system, so here we go again to setup a brand new Raspberry Pi... enter Alfred, the new housekeeper.

Migrating UniFi Controller to Kubernetes

The old UniFi Controller and its required Mongo DB have been a bit of a hassle to keep updated while running directly on the host OS in my little homelab server, so the time has come to migrate this to the new linuxserver.io/docker-unifi-network-application on my little Kubernetes cluster on my new Kubernetes cluster.

Warning

Beware of outdated documentation, most articles out there like Install Unifi Controller on Kubernetes, are based on the deprecated linuxserver/unifi-controller, while others like setting up the UniFi Network Controller using Docker are using jacobalberty/unifi-docker which was quite outdated until recently.