Build Notes 1: A Rock 5T Kubernetes Cluster That Did Its Homework

Most small-board Kubernetes clusters have the same problem: they are clusters in the literal sense, but compromises in every practical sense. One network port. Storage that should have stayed in a camera. Enough RAM to run a demo. Then a software stack chosen mostly because the hardware would collapse under anything heavier.

Dual-O shared the build in a post on r/homelab. The full build notes, bill of materials, setup outline, power table, photos, and follow-up notes are in the Radxa forum write-up.

It starts from the other end: three Rock 5T nodes with enough network, storage, memory, and power discipline to make Talos, Cilium BGP, Gateway API, Longhorn, and Flux look intentional rather than optimistic.

The short version: three Rock 5T boards, NVMe per node, dual 2.5GbE per node, PoE power, and a published whole-setup wall-power figure of about 27 W idle including the switch.

This is a sourced build profile, not a Suite Despair hardware review or a recommendation to buy the same parts.

What Dual-O Built

The cluster uses three Radxa Rock 5T boards. Each node is based on Rockchip’s RK3588, with 24 GB LPDDR5, two native 2.5GbE ports, and a 1 TB Crucial P510 NVMe drive.

Across the cluster, that gives:

Part of the build	What Dual-O used
Nodes	3 x Radxa Rock 5T
SoC	Rockchip RK3588
Memory	24 GB LPDDR5 per node, 72 GB total
Networking	2 x native 2.5GbE per node
Storage	1 TB NVMe per node
Power	Radxa 25 W PoE+ modules
Switch	Ubiquiti Flex 2.5G PoE
Operating system	Talos Linux with a Rock 5T overlay
Kubernetes network	Cilium with kube-proxy replacement and BGP Control Plane
Ingress model	Gateway API
Cluster storage	Longhorn with three replicas
Deployment model	Flux GitOps

Each row removes one of the usual excuses from the small-board cluster.

The extra memory keeps the nodes from being treated like disposable edge toys. NVMe per node gives persistent storage a credible base for replicated volumes instead of SD or eMMC. The second network port gives pod traffic its own path instead of sharing one with management, ingress, and externally advertised services. PoE tidies the power path: one upstream feed through the switch instead of three separate USB-C bricks and the cable nest that normally follows.

Hardware First, Stack Second

The hardware was chosen for the stack. A lot of small Kubernetes builds go the other way. They start with boards that are fun, cheap, or already in a drawer, then trim the software until it fits. Useful for learning. Less convincing when the goal is a local twin of a real deployment model.

Here, Talos, Cilium BGP, Gateway API, Longhorn, and Flux each have a physical requirement underneath:

• Talos fits machines you can rebuild and manage as Kubernetes nodes, not little general-purpose pets.
• Cilium BGP needs networking that can carry the design instead of one overworked port.
• Gateway API assumes an ingress model worth treating as infrastructure.
• Longhorn needs real per-node storage.
• Flux only pays off if the cluster state lives somewhere more durable than a weekend’s shell history.

Two NICs Change The Cluster

The plainest Rock 5T feature does a lot of work here: two native 2.5GbE ports per node.

Dual-O uses the ports for separate roles. One side handles management, ingress, and BGP-advertised services. The other side is isolated for pod-to-pod traffic. The exact addressing and router details belong in the original write-up. The portable idea is simpler: if the board gives you two ports, stop asking one of them to carry every job.

Cilium’s BGP Control Plane exists to advertise routes to connected routers in environments that support BGP. In a small home cluster, that can replace a more appliance-like load-balancer pattern with something closer to how networked infrastructure usually behaves.

The two-port split does not make the cluster enterprise. It makes the lab less silly. Management, ingress, external reachability, and pod traffic are different jobs. Once somebody separates them cleanly, the single-port compromise looks worse in hindsight.

NVMe Makes Longhorn More Plausible

Longhorn is often where small Kubernetes clusters start writing cheques the hardware cannot cash.

The project is a Kubernetes-native distributed block storage system. Its own documentation describes volumes with engines and replicas, with replicas placed across nodes or disks. Useful, but not light magic. The devices underneath still set the ceiling.

Dual-O’s build uses one 1 TB NVMe drive per node and a three-replica Longhorn layout. The board gives each node local NVMe, a much better foundation for replicated cluster storage than removable flash.

Longhorn replicas are not a permission slip to stop thinking about backups. They can help a volume survive node or disk trouble inside the cluster. They do not protect against bad deletes, bad application writes, broken upgrades, or operator mistakes.

Talos And Flux Keep The Nodes From Becoming Pets

Talos treats the machines as Kubernetes infrastructure: no SSH for normal management, API-driven control, and a machine configuration workflow built around Kubernetes rather than around whoever is managing it that week.

On small boards, that drift starts quickly. If each node becomes a hand-maintained ARM Linux box, the cluster quietly turns into three pets with matching collars. It may still work, but it stops being a useful model of rebuildable infrastructure.

Flux fills the other half of that pattern by keeping Kubernetes configuration in sync from a source of truth such as a Git repository. In a home lab, GitOps can easily become theatre if the underlying system is fragile. In this build, it makes sense because the rest of the stack is also trying to be rebuilt, not merely remembered.

The value is not purity. When something breaks, a cluster you can reflash, rejoin, and reconcile from versioned configuration is a better lab than one that depends on remembering which command fixed the thing last Tuesday.

27 W Idle, Including The Switch

The Radxa forum post includes a power budget table for the whole setup. Dual-O reports roughly:

Component	Idle	Peak
3 x Rock 5T nodes plus NVMe, including PoE+ overhead	20 W	45 W
Flex 2.5G PoE switch	7 W	9 W
Total at the wall	27 W	54 W

A three-node Kubernetes setup at about 27 W idle including the switch, with real storage and network separation, becomes a practical domestic object.

The cluster runs from one upstream power path through the PoE switch rather than three separate board power supplies. That changes cable management, placement, and how the build can live in a small space. The cable situation decides whether the thing remains tolerable after the first weekend.

Dual-O also published a follow-up describing fan control as a Kubernetes DaemonSet. The container runs with the access needed to control the board fan through sysfs, discovers the thermal and PWM paths, and uses a curve that accounts for the underside NVMe position. The public notes describe the noise subjectively and leave fuller performance, utilization, and temperature graphs for a later follow-up.

The thermal story is unfinished, but power and cooling were in the design before the boards start sulking.

Physical constraints and software ambition point in the same direction here. That leaves a more useful object than a tidy stack photo: a 27 W idle cluster with real storage, two network paths, and a cooling plan already in motion.

Sources And Credit

Build and photos: Dual-O. Original posts:

• Reddit: Built a proper 3-node Kubernetes cluster on Radxa Rock 5T SBCs with Talos, Cilium BGP, Longhorn, Gateway API, Flux
• Radxa Community: Rock 5T Talos Kubernetes Cluster

Supporting documentation:

• Radxa ROCK 5T product page
• Talos Linux FAQ
• Cilium BGP Control Plane
• Longhorn concepts
• Flux documentation