Why k3s?
When I set out to build a production-grade MLOps platform on a 16 GB homelab machine, the first question was obvious: which Kubernetes distribution?
Full K8s (kubeadm) gives you flexibility, but on a memory-constrained node the control plane overhead is non-trivial. k3s ships a single binary — server and agent — and consumes roughly 500 MB less RAM at idle. For a homelab that also needs to run MLflow, MinIO, Prometheus, and model inference workloads, that headroom matters.
What You Give Up
- No built-in etcd by default (k3s uses SQLite for single-node, or embedded etcd for HA). For a homelab this is fine. In production, you’d want external etcd.
- Some upstream admission webhooks behave differently. I hit one with OPA/Gatekeeper on first install.
- Fewer knobs for fine-grained control plane tuning.
The Bootstrap Sequence
# Install k3s without Traefik (we'll bring our own ingress)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -
# Export kubeconfig
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
From here, everything else comes via GitOps. The cluster bootstrap creates a single FluxCD HelmRelease that then pulls the rest of the platform manifests from the Git repo.
Lessons from Phase 1
The real value of going through this manually — rather than using a managed cluster — is that you understand what each component does. When something breaks (and it will), you know where to look.
Starting with k3s and GitOps means the cluster is declarative from day one. No manual kubectl apply commands that you’ll forget about in three weeks.