Let’s setup Gitlab CI to trigger a rolling restart of a Kubernetes deployment. This is a lightweight alternative to a something like Flux which requires an operator running in the cluster.

This is the debugging story of a strange 12 minute hang I’d get after logging in to my SFTP server. It wasn’t the usual culprits, and it wasn’t any of the likely cloud complications. Instead it turned out to be an issue as old as POSIX itself.

Let’s deploy our own peer-to-peer Dropbox-like system with Syncthing, Nginx, and Kubernetes.

I am going to describe how I store all of my Kubernetes manifests in a single directory tree. The overriding goals of this setup is to commit all of the manifests to version control, and to apply them with a single command.

Helm is an easy way of deploying to Kubernetes, but helm install is a bit annoying because it doesn’t save the changes it made to a local repo. That’s where helm template comes in.

I recently setup Umami on this blog to get some basic analytics. The deployment on Kubernetes was easy, but it required some spelunking into documentation. Here are my notes.

I just switched some of my Kubernetes nodes to run on a root ZFS system. It was mostly painless, but there were a few places that required special configuration. Here are my notes.

Kubernetes networking is complicated. It’s not complex, mind you, as there’s no emergent behaviour. It’s just complicated because there are lots of moving parts that are used in different circumstances. Let’s explore how the parts fit together by walking through several scenarios.