Homelab

Commands and manifests for Cybertron, a three-node Talos Linux Kubernetes cluster on refurbished mini PCs, as built in the blog series. Each folder matches one part.

It's a cluster to break on purpose: networking, storage, observability, GitOps, upgrades and node failures on real machines, real Ethernet and real disks, without paying for cloud resources or breaking an environment someone else depends on.

Part	Post	Folder
1. A highly available cluster with Talos Linux	Building a 3-Node Highly Available Kubernetes Homelab with Talos Linux	talos/
2. Networking: Cilium, Gateway API, cert-manager, Cloudflare Tunnel	Networking a 3-Node Kubernetes Homelab with Cilium, Gateway API and Cloudflare Tunnel	networking/
3. Remote access with Tailscale	Tailscale on Talos Linux: Secure Remote Access to a Kubernetes Homelab	tailscale/
4. Omni	Importing an Existing Talos Cluster into Omni	omni/
5. Storage with Longhorn	Persistent Storage for a 3-Node Talos Homelab with Longhorn	storage/

The cluster

Three identical machines, all control planes, all running workloads:

Node	Address	Role
optimus	192.168.1.111	Control plane, etcd, workloads
bumblebee	192.168.1.112	Control plane, etcd, workloads
ratchet	192.168.1.113	Control plane, etcd, workloads

• Kubernetes API VIP: https://192.168.1.200:6443. Talos moves it to a healthy control plane, so kubectl doesn't depend on any one machine.
• etcd: three members, quorum two. One node can go down; two can't.
• No SSH: Talos is immutable and managed through its API. talosctl talks to each node's own IP (machine: config, disks, logs, upgrades); kubectl talks to the Kubernetes API through the VIP.
• Node addresses come from DHCP reservations on the router. The VIP and the LoadBalancer range are reserved too, so DHCP never hands them to another device.

Hardware

	Each node
Machine	Dell OptiPlex Micro (refurbished)
CPU	Intel Core i5, 8th gen
Memory	8 GB DDR4
Disk	256 GB SATA SSD
Network	Wired Ethernet to the home router

Lenovo ThinkCentre Tiny or HP EliteDesk/ProDesk Mini machines work the same way; nothing here depends on Dell.

Networking

Cilium is the CNI and replaces kube-proxy. Apps are reached through one of two Gateways, and the route's parentRef decides which:

	Lab apps	Public apps
Names	<app>.lab.prateek.cloud	<app>.prateek.cloud
Reached from	The home LAN only	The internet
Path	LAN → 192.168.1.201 → Gateway internal → pods	Cloudflare edge → tunnel → cloudflared ×2 → Gateway public → pods
TLS	Let's Encrypt wildcard from cert-manager (DNS-01, so no inbound access needed)	Cloudflare's edge certificate

• LoadBalancer IPs: Cilium LB IPAM hands out 192.168.1.201–205, and L2 announcements make one node answer ARP for each IP (it moves if that node goes down).
• No open ports at home: public traffic arrives through one shared Cloudflare Tunnel that the cluster opens from the inside.
• NetworkPolicy is enforced (it wasn't with Flannel), and Hubble shows every flow and drop.

Details and the full migration from Flannel: networking/.

Remote access

Tailscale runs on all three nodes as a Talos system extension, so kubectl, talosctl and the lab apps work from anywhere with the same addresses, certificates, kubeconfig and talosconfig as at home.

• Five /32 routes, not the LAN: the three node addresses (Talos API), the API VIP 192.168.1.200 and the internal Gateway 192.168.1.201. The router, phones and everything else on the network stay unreachable.
• High availability: every node advertises the same routes; one is active and another takes over when it goes down.
• Access policy: members of the tailnet reach only ports 80/443 on the Gateway, 6443 on the VIP and 50000 on the nodes. The nodes are tagged devices with no key expiry, and the auth key is revoked after they join.
• No open ports at home, and the Talos API stays reachable even when Kubernetes is down.

Details, the gotchas (node IPs, Cilium MTU, extension config before the upgrade) and the failover test: tailscale/.

Storage

Each node's single SSD is split in two: a 60 GiB /var for Talos and a 170 GiB user volume at /var/mnt/longhorn. Longhorn replicates volumes across the nodes and is the default StorageClass.

• Two replicas per volume on different nodes, so a node can go down and Longhorn still has a third node to rebuild the missing copy on. That's 255 GiB of volumes in total.
• Snapshots every hour, kept for a day; optional backups every night to AWS S3, kept for two weeks.
• Node failures: a pod on a powered-off node is force-deleted and its volume attaches where the replacement runs.
• UI at https://longhorn.lab.prateek.cloud, LAN and tailnet only (it has no login).

Details, the EPHEMERAL reset and the failure tests: storage/.

Versions

Component	Version
Talos Linux	1.14.3
Kubernetes	1.36.4
Cilium	1.20.2
Gateway API CRDs	v1.6.1
cert-manager	v1.21.2
cloudflared	2026.10.0
Tailscale (Talos extension)	1.102.3
Longhorn	1.13.0

What's next

• Observability: Prometheus and Grafana, the first real tenants of the Longhorn volumes.
• Later: GitOps with Argo CD, an auth proxy in front of the lab apps, and security tooling.

Repository layout

Path	What
talos/	Part 1: install, bootstrap and validate the Talos cluster
networking/	Part 2: Cilium, LB IPAM, Gateways, cert-manager, Cloudflare Tunnel, demo app and tests
tailscale/	Part 3: Tailscale extension, subnet routes, access policy, failover
omni/	Part 4: import into Omni, Talos 1.14 node patches, static IPs, undo patch
storage/	Part 5: system extensions through Omni, the Longhorn partition, Longhorn, snapshots, optional S3 backups
assets/	Diagrams used in this README
.github/workflows/	CI on every push: yamllint, kubeconform (Kubernetes 1.36 and the CRDs used), gitleaks, link check

Replace the domain and 192.168.1.x addresses with your own. Credentials never go in this repository: generated Talos configuration, talosconfig, kubeconfig, API tokens, tunnel and S3 credentials stay local (see .gitignore) or in Kubernetes Secrets created by hand.

License

MIT. Use, copy and adapt anything here for your own lab.

Follow the series

For the next parts, follow along on blog.prateekjain.dev, X (@PrateekJainDev) or LinkedIn (in/prateekjaindev).