Building a Home Lab Kubernetes Cluster with k3s on VMware Workstation
For systems administrators in Brisbane, Melbourne, or Perth, a home lab is one of the most reliable ways to rehearse production patterns before touching a paying customer. Kubernetes has moved from a Silicon Valley curiosity to a baseline skill across Australian enterprises, from the banks in Sydney's Barangaroo to resource companies in Western Australia. Practising on real infrastructure rather than managed services builds the muscle memory you need when a pager fires at three in the morning AEST.
VMware Workstation is an obvious foundation for that practice environment. It runs on a beefy desktop in a home office in Adelaide or Canberra, supports nested virtualisation on modern Intel and AMD processors, and lets you snapshot your way back from any misconfiguration. Pairing it with k3s, the lightweight Kubernetes distribution from Rancher Labs, gives you a cluster that boots in under a minute and tolerates modest hardware.
The patterns below scale from a single-node lab to a three-node control plane, tested on a Windows 11 host with 64 GB of RAM.
Why k3s Suits a VMware Workstation Lab
k3s packages the core Kubernetes components into a single binary and uses embedded etcd for multi-node clusters, or SQLite for single-node deployments. The footprint fits a VMware Workstation VM with 1 GB of RAM and a single vCPU, which matters when juggling a control plane and several workers on a desktop in Hobart or Darwin.
Australian network conditions also favour this approach. Most homes connect through the NBN, and latency to overseas container registries can be noticeable. k3s supports a private registry mirror, air-gapped installs, and an embedded service load balancer that removes the need for an external HAProxy VM. These features reduce reliance on trans-Pacific throughput.
The project ships with predictable, conservative release notes. For an IT generalist juggling a day job and after-hours study, that stability is worth more than bleeding-edge features.
Preparing the Virtual Environment
Allocate three VMs in VMware Workstation: one k3s-cp for the control plane, and two workers named k3s-w1 and k3s-w2. Use Ubuntu Server 22.04 LTS for familiarity, although Rocky Linux 9 works if you prefer a Red Hat lineage. Give the control plane 2 vCPUs and 2 GB of RAM, and 1 vCPU with 1.5 GB to each worker. Enable VT-x/AMD-V and tick nested virtualisation if you plan to use KubeVirt.
Configure each VM with a host-only network so nodes can communicate without depending on your home router. In Australian homes this matters because routers from Telstra or Optus often default to AP isolation, which silently breaks cluster traffic. Add a NAT interface for outbound internet so each node can pull images.
Snapshot each VM before installing anything. This habit saves hours when an upgrade goes wrong. Store the snapshots on a fast NVMe drive; a 1 TB Samsung 980 costs roughly the same in Sydney as in Seattle.
Deploying k3s Across the Cluster
On the control plane, install k3s with the embedded etcd datastore enabled. The single command bootstraps the API server, scheduler, and controller manager, then writes a node token to /var/lib/rancher/k3s/server/node-token. Copy that token to a secure location because workers need it during join.
Workers join with the K3S_URL and K3S_TOKEN environment variables. After about thirty seconds, kubectl get nodes should show all three VMs in Ready state. You now have a functional cluster running entirely on-premises, with no dependency on AWS Sydney or any external managed control plane. That independence is useful when rehearsing disaster recovery.
Install VMware Tools on each VM so clipboard sharing and time synchronisation work. Time sync is critical for certificate validation, and a drifted clock is one of the most common reasons a fresh cluster fails health checks. Accurate time is non-negotiable for GitOps tooling such as Argo CD.
Storage, Networking, and Persistent Workloads
Lightweight Kubernetes distributions vary in storage and ingress defaults, which is worth comparing before you commit.
| Feature | k3s | microk8s | kind |
|---|---|---|---|
| Default storage | Local-path provisioner | Hostpath storage | EmptyDir only |
| Built-in ingress | Traefik (optional) | NGINX or Traefik addon | None |
| HA control plane | Embedded etcd | Dqlite | External etcd container |
| Idle RAM overhead | ~250 MB | ~400 MB | ~300 MB |
| Bare-metal friendly | Yes | Yes | Limited |
For most Australian home labs, k3s offers the best balance. The local-path provisioner creates persistent volumes without extra configuration, and the embedded Traefik controller exposes services to a browser. If you want to experiment with Rook or Longhorn, allocate a second virtual disk to each worker. Three 20 GB disks are enough to learn the basics.
Networking requires attention because of NBN's variable upload speeds. To expose a service to another device on the same Wi-Fi, set the Traefik service type to LoadBalancer and bind it to the host-only interface. Avoid bridging to the physical NIC directly, which exposes the lab to every device on the home network, including the smart fridge.
Day-Two Operations and Real Workloads
Once the cluster is healthy, push real workloads through it. A useful starting point is MetalLB, which teaches how services get addresses in a bare-metal environment. Install cert-manager and a small WordPress instance to validate persistent storage end to end. The Australian dollar stretches well across a year of running this lab on commodity hardware, and the lessons transfer directly to clusters run by ANZ, CBA, and many mid-tier employers.
Habits to keep the lab useful long term:
- Automate node provisioning with a small Ansible playbook stored in a private Git repo so you can rebuild in an afternoon.
- Mirror the small set of container images you actually use through a local registry to avoid trans-Pacific pulls during the evening.
- Schedule weekly upgrade rehearsals on a clone of the lab so the first production upgrade is not the day before a change.
- Document the cluster topology in a single Markdown file alongside your playbooks, including which VMware Workstation snapshot represents a known-good state.
Treat the home lab as a disposable environment that you rebuild often. That mindset prepares you for the realities of cloud-native operations, where clusters are cattle rather than pets and every component is redeployable from code rather than memory.