First Migrations Off the VMs
With the platform roughly stable, the work shifts from “build the cluster” to “start actually moving things off the old VMs” — though not in a straight line.
The first named migration
27 April 2026 carries the first commit that names what it’s doing plainly:
“feat(migration): add debian-dev01 K8s migration — phase 1-3.” This is the
moment the project stops being purely about the cluster itself and starts
being about the VM it was meant to replace. The same day, Longhorn — installed
back on 9 April — was tried as the storage backend for this migration and
abandoned in favour of nfs-subdir-external-provisioner instead, and Kanboard
was switched to run on SQLite rather than depending on a database service at
all. Both were pragmatic downgrades in complexity, not upgrades — a pattern
that recurs: sometimes the simpler storage option is the right one for a given
app, even inside a cluster that also runs a proper replicated block-storage
system.
By 28 April, ddclient had been fully removed from debian-dev01’s
responsibilities, and UniFi’s Network Application made its first appearance
in-cluster. It wouldn’t stay — this early UniFi deployment gets disabled again
three weeks later (see the next chapter) and isn’t properly re-migrated for
good until August. Not every “first attempt” in this project’s history stuck
the first time.
2 May: three foundational systems in one day
The next real leap forward lands all at once on 2 May, alongside a Talos 1.13 / Kubernetes 1.36 upgrade:
- Authentik arrives as the cluster’s OIDC/SSO identity provider — nothing before this point had centralised authentication; every app either had its own local accounts or none at all.
- Knative Serving and Eventing go in, giving the cluster its first scale-to-zero serverless layer — used almost immediately afterward for small utility services rather than anything resource-hungry.
- Harbor moves onto NFS storage, decoupling the registry from whatever storage class experiment was currently in favour.
Monitoring grows up, Longhorn goes away (for now)
Over the following week, Prometheus, Grafana and Alertmanager are re-enabled
with Authentik sitting in front of Grafana’s login — the first app to actually
use the SSO layer just added. And on 4 May, in a commit titled plainly
“chore(longhorn): remove all Longhorn artefacts,” the storage system tried
twice already in three weeks is pulled out completely. It would come back —
properly, and for good — in July. For now, nfs-client carries everything.
What this stretch actually established
By 8 May, the shape of “a migration” for this project had become clear, even if nobody wrote it down as a checklist: move one VM’s responsibility at a time, pick the simplest storage option that actually works rather than the most sophisticated one available, and don’t be afraid to disable something that isn’t pulling its weight yet and come back to it later. That patience is what makes the next, much stranger chapter possible.