I figured out how to access Kubernetes services on my cluster without the need for kubectl port-forward or an ingress. It can all be done with Linux routing tables, and Wireguard makes this trivial to set up.

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.

Many recent distributed programs like etcd or Kubernetes require TLS certificates to communicate securely. Creating these by hand is tedious, so let’s see how to automate it with a nix flake.

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

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.

Wireguard is a nifty little tool. The tagline describes it as an “extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography”. I have been using it for years to tunnel into my servers, as an Internet gateway, and as a jumpbox into the servers’ VLAN. Recently, I figured out how to configure it as a secure mesh between the servers.

I needed a way to store my personal documents remotely in a secure way, so I came up with a scheme involving GCE, nbd, wireguard, and cryptsetup.