Ever since the new, more powerful
octavo
replaced the good old
lexicon
server as the single-node Kubernetes cluster to serve all the local self-hosting needs,
the latter has not found any use. Since it would be a waste to let it sit in a box
unused, it will be setup to join the (for now) single-node cluster that is octavo to
enable Zero Downtime Maintenance.
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.
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 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.
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.
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.
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.
Need. More. Server. Need. More. POWER!!!
Just a bit more, maybe quite a bit more, to run services that are more CPU-intensive than those already running in the current Single-node Kubernetes cluster on an Intel NUC: lexicon.
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.
Upgrading the single-node kubernetes cluster on rapture
went smoothly, so it's time to repeat the process on lexicon, especially
since the current version (1.26) will be
End Of Life next month!