Skip to content

kubernetes

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.

ddns-updater on Kubernetes

After years of enjoying a static IPv4 address for free, migrating to a new ISP required either paying a monthly fee for such a priviledge... or simply running a Dynamic DNS service to keep the relevant domains pointing to the correct IPv4 address as it updated.

Playing Steam games in the browser with self-hosted Headless Steam Service

Headless Steam is like a self-hosted GeForce NOW, which can be useful to play games in a browser while away on holidays. Although mainly intended to play Steam games, it also supports EmeDeck, Heroic and Lutris, all easy to install via Flatpak, and supports Intel GPU which is already setup for Jellyfin on Kubernetes with Intel GPU and not actually getting a lot of use; running games would probably be a better use of that Intel UHD GPU.

Tracking progress with Ryot

Sometimes I wish for a centralized, automatically updated and moderately fancy-looking application to keep track of multiple activities; mostly around digital media.

  • Audiobookshelf is pretty good but separates podcasts from books and only shows yearly summary at the end of the year. Audible does not offer even that, and no export options.
  • Jellyfin (and previously Plex) don't go beyond marking things as "done". Besides, movies and TV shows are not the kind of videos I'm intersted in tracking progress with; video lectures are (where was I with this Inkscape course?).
  • Paper books are very nearly not even a thing anymore, but it would still be nice to be able to track progress on them, as well as reading e-Books in Komga.
  • Video games are absurdly difficult to track progress for. Naturally grown from need, a spreadsheet is works well enough to collect data across multiple platforms, but it is limited, ugly and increasing slow as the library grows.
    • Steam shows only total and recent (last 2 weeks) gameplay, and probress is tracked in terms of achievements, not how close you are to finish the main story. At least there is the option to query the Steam Web API to periodically fetch gameplay stats, so they can be kept at a higher resolution (daily, hourly, etc.).
    • Nintendo Switch Parental Control (Android app). shows only gameplay time per game (and per user) in the current month, after that it shows only montly summaries. There is no option to export any of this.
    • GOG requires installing their own (Windows-only) Galaxy 2.0 client and the possiblity of exporting or even seeing your personal gameplay stats appears to be not even a question.

Looking around for tracking applications in the awesome directory of awesome-selfhosted, two applications look promising and worth a try: Ryot and Yamtrack.

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.