Why I Run Kubernetes on Talos, on Proxmox (Series: Part 1)

I rebuilt my home Kubernetes cluster on Talos Linux running as VMs on Proxmox. This is the first post in a series documenting that stack — the why before the how. If you’re weighing how to run k8s in a lab, the OS choice matters more than people give it credit for.

The problem with “just install k8s on Linux”

The classic homelab path is a few Ubuntu or Debian VMs, kubeadm, and a pile of shell scripts. It works, and then it rots. Six months later you can’t remember which node got which manual tweak, an apt upgrade shifts a kernel module, and a control-plane node won’t rejoin after a reboot. The cluster becomes a pet, not cattle, and the OS underneath is a mutable surface you have to babysit.

The insight that fixed it for me: in Kubernetes, the node OS should be an appliance, not a server you log into.

What Talos gives you

Talos Linux is a purpose-built, immutable OS for Kubernetes and nothing else:

• No SSH, no shell. You don’t log in. The entire system is managed through a declarative API (talosctl) and a YAML machine config. There’s no console to drift.
• Immutable, minimal root. The OS image is read-only and tiny — far less attack surface and nothing to patch by hand. Upgrades are atomic image swaps with rollback, not in-place package churn.
• Config as data. A node’s identity is a single machine-config file. Rebuilding a node is applying that file to a fresh VM — no snowflake state to reconstruct.

That last point is the one that changes day-to-day life. A node is fully described by its config. Lose one, stamp out a new VM, apply the config, it rejoins. Cattle, not pets.

Why Proxmox underneath

Talos boots happily as a VM, and Proxmox gives the lab-friendly substrate:

• Cheap, disposable VMs for control-plane and worker nodes — spin up, tear down, resize without touching hardware.
• Snapshots before a risky cluster change, so “undo” is a click.
• Clean separation between the hypervisor I already run everything else on and the k8s nodes, instead of dedicating bare metal.

The combination — immutable nodes on disposable VMs — means both layers are reproducible. The hypervisor makes the machines disposable; Talos makes their OS declarative. Nothing in the stack is hand-built and unrepeatable.

What’s coming in this series

This stack is committed as infrastructure-as-code, and the next posts will walk through it concretely:

• Bootstrapping the control plane with talosctl and machine configs
• VM sizing and Proxmox layout for control-plane vs workers
• Networking, the CNI choice, and how ingress ties back to the existing edge
• Storage: what backs persistent volumes in a Proxmox lab
• Backup and disaster recovery for cluster state

The theme throughout: if it isn’t reproducible from a file, it doesn’t belong in the cluster. Talos enforces that at the OS layer, and that constraint is the whole point.