K3s
Journey to K3s: Accessing from the Outside
Up until now I have been working locally (on my home network). While that is enough for most of the services I’m running I need to access some of them from the outside. For example, I want to expose this blog to the internet and access Miniflux to read my RSS feeds on the go.
There are a few ways to achieve this but I have some specific requirements that I want to meet:
- Zero-trust approach: I don’t want to expose the services directly to the internet.
- Public services: Other clients apart from me should be able to access some of the services.
- Home IP safety: Don’t directly expose my home IP address. (This is on par with #1, but I want to make it explicit).
- On-transit encryption: Full on transit encryption from the client to the cluster with no re-encryption in the middle.
- No Cloudflare. (Breaks #4)
- No Tailscale. (Breaks #2, also there are other users at home and I don’t want to have the Tailscale client running all the time).
What does this leave me? A reverse proxy server.
Journey to K3s: Basic Cluster Backups
There a time to deploy new services to the cluster, and there is a time to backup the cluster. Before I start depending more and more of the services I want to self-host it’s time to start thinking about backups and disaster recovery. My previous server have been running with a simple premise: if it breaks, I can rebuild it.
I’m going to try and keep that same simple approach here, theoretically if something bad happens I should be able to rebuild the cluster from scratch by backing up cluster snapshots and the data stored in the persistent volumes.
Importing data manually into a longhorn volume
I was in the process of migrating Shiori from my docker environment to the new k3s cluster I’m setting up. Shiori is a bookmarks manager that uses an SQLite database and a folder to store the data from the bookmarks. I didn’t want to switch engines just yet since I want to improve SQLite’s performance first, so I decided to move the data directly to a longhorn volume.
This probably is super simple and vastly known but it wasn’t clear for me at first. Posting it here for future reference and for anyone that might find it useful.
Journey to K3S: Deploying the first service and its requirements
I have my K3S cluster up and running, and I’m ready to deploy my first service. I’m going to start migrating one of the simplest services I have running in my current docker setup, the RSS reader Miniflux.
I’m going to use Helm charts through the process since k3s supports Helm out of the box, but for this first service there’s also some preparation to do. I’m missing the storage backend, a way to ingress traffic from the internet, a way to manage the certificates and the database. Also, I need to migrate my current data from one database to another, but those are postgresql databases so I guess a simple pg_dump
/pg_restore
or psql
commands will do the trick.
Journey to K3S: Basic cluster setup
I’ve finally started to play with K3S, a lightweight Kubernetes distribution. I have been reading about it for a while and I’m excited to see how it performs in my home lab. My services have been running in an Intel NUC running Docker container for some years now, but the plan is to migrate them to a k3s cluster of three NanoPC-T6 boards.
I was looking for a small form-factor and low power consumption solution, and the NanoPC-T6 seems to fit the bill. I know I’m going to stumble upon some limitations but I’m eager to see how it goes and the problems I find along the way.
My requirements are very simple: I want to run a small cluster with a few services, and I want to be able to access them from the internet and from my home. My current setup relies on Tailscale for VPN and Ingress for the services, so I’m going to try and replicate that in this new setup.