Text size
Tried & Tested6 min read

Kubernetes at home: Talos, k3s and a homelab

A small cluster on cheap hardware, and what it teaches you about production.

Kubernetes at home: Talos, k3s and a homelab
AI-generated editorial illustration

At work, Kubernetes usually comes pre-built. A managed service, a platform team, a few clicks or a Terraform module, and the cluster exists. That's great for productivity, and terrible for learning how things actually work underneath.

A homelab fixes that. A few small machines on a shelf, a cluster you built yourself, and nobody to blame but you when it breaks. It's one of the best learning investments I know.

Why build a homelab

  • You learn the layers managed services hide: networking, storage, certificates, the control plane, upgrades.
  • You can break things freely. No change tickets, no customers.
  • You can try tools before proposing them at work: GitOps, service meshes, observability stacks, policy engines.
  • It's genuinely useful. Many people run their home services (media, backups, home automation, password managers) on it.
  • It looks good on a CV, especially when you write about it.

What hardware?

You don't need much:

  • Mini PCs (Intel NUC style or similar) are the most popular choice: quiet, efficient, x86, enough RAM.
  • Raspberry Pi boards work well with lightweight distributions, but ARM and SD card storage add some quirks.
  • One old laptop or desktop with virtual machines is a perfectly fine start.

Three nodes is a good target: enough to learn high availability and what happens when a node dies. Plan for at least 8 GB of RAM per node, and use SSDs rather than SD cards for anything you care about.

Talos vs k3s

Two distributions stand out for homelabs, and they have very different philosophies.

k3s is a lightweight, fully compliant Kubernetes distribution from Rancher (SUSE). A single binary, installed on a normal Linux system with one command:

curl -sfL https://get.k3s.io | sh -

It comes with sensible defaults built in: a container runtime, networking, a local storage provisioner and an ingress controller. It's the fastest way to a working cluster, and very forgiving.

Talos Linux takes a radical approach: it's an operating system built only to run Kubernetes. No SSH, no shell, no package manager. Everything is configured through an API with talosctl and a YAML machine configuration. The OS is immutable, so nodes can't drift, and upgrades are atomic.

talosctl gen config homelab https://192.168.1.10:6443
talosctl apply-config --insecure --nodes 192.168.1.10 --file controlplane.yaml
talosctl bootstrap --nodes 192.168.1.10

My take: k3s if you want to learn Kubernetes quickly, Talos if you want to learn how production-grade, immutable infrastructure feels. Talos is stricter and has a steeper start, but once it clicks, it's hard to go back to SSH-ing into nodes.

Other options worth knowing: k0s, MicroK8s, and plain kubeadm if you want to do everything the hard way at least once.

A homelab teaches you more in one broken weekend than a managed cluster teaches you in a year.

A stack worth building

Once the cluster runs, here's a learning path that mirrors real production setups:

  1. GitOps with Argo CD or Flux. Everything in Git from day one.
  2. Networking with Cilium, and MetalLB or Cilium's own load balancer support to get real IPs for services at home.
  3. Gateway API with cert-manager and Let's Encrypt for HTTPS.
  4. Storage with Longhorn or a simple NFS provisioner.
  5. Observability: Prometheus, Grafana, Loki.
  6. Secrets with External Secrets or SOPS.
  7. Backups with Velero to an external disk or cloud storage.

Each step teaches something you'll use at work.

Lessons for real work

The things a homelab taught me that managed clusters never did:

  • Networking is most of the difficulty. IP ranges, DNS, load balancers, MTU problems.
  • Storage is the hardest part of reliability. Losing a disk in a homelab makes backups very real.
  • Upgrades need practice. Doing them regularly on your own cluster makes production upgrades much less scary.
  • Immutable infrastructure is worth it. Rebuilding a node from config beats fixing it by hand.
  • Write things down. Future you will not remember why that one setting exists.

So, is it worth it?

If you work with Kubernetes, or want to, absolutely. It costs a few hundred euros, or nothing if you reuse old hardware, and some evenings. In return you get a deep understanding of the system you work with every day.

My take: build it yourself at least once. You'll understand every managed cluster you touch afterwards a little better.

— Desly