What you need
Check this list before you unbox anything. Nothing here is unusual or expensive, but a couple of items — RAM on the first machine, and everything sitting on the same network — will stop you cold partway through setup if you skip them.
Machines
You need at least three machines: one to run the cluster’s control (the master), and at least two more to add to it (workers). Two are the minimum tested configuration; the full setup, add, verify and remove cycle is validated against exactly that shape.
| Role | Minimum | Recommended |
|---|---|---|
| Master | 4-core ARM64 board, 2 GB RAM | Same, with 4 GB RAM for more headroom |
| Workers | 2 machines of the same kind | Same |
| Power | — | a quality, official-spec power supply per machine; an underpowered supply causes instability |
The 2 GB minimum for the master isn’t a rough guess: a configured master idles at roughly 1 GB of memory with no other load, before any of your own applications run, so a machine with 1 GB cannot hold it. A smaller board (roughly 1 GB of RAM) can still work as a worker; it just cannot be the master, and it’s not recommended even as a worker, since it leaves little room for your applications.
All the machines in one cluster must match architecture. A cluster built on ARM64 boards takes only ARM64 workers; a cluster built on x86-64 machines takes only x86-64 workers. Mixing the two isn’t supported yet, so decide on one before you buy the second and third machine.
Boot media and storage
- Each machine needs its own boot storage: a memory card (Class 10, A1 or better, 16 GB or larger) works for the operating system and the cluster software itself, or a higher-endurance card, or a boot-capable SSD, if you’d rather.
- Put the data your applications actually keep on a separate USB disk attached to a node, not on the boot card. An SSD is strongly preferred over a spinning disk for both endurance and speed.
- That disk’s data lives on one node — whichever one it’s physically attached to — and there is no copying it to another disk for safety. If that node or its disk fails, the data on it goes offline until you fix or replace it. You can still let an app running on a different node reach the data over the cluster’s own private network (a shared storage), but “reachable from elsewhere” is not the same as “backed up elsewhere”: back up anything you can’t afford to lose.
Network
- One local network. Every machine — the master and every worker — needs to be on the same local network, connected by wired Ethernet. This is the requirement most likely to trip you up if your workers are in a different room on a different switch.
- Only the master needs to be reachable directly. You’ll open the web panel at the master’s own address; the other machines talk to the master and each other over an encrypted connection the cluster sets up for itself. You never address a worker directly.
- SSH, briefly. Each worker needs SSH reachable for the one-time step of adding it to the cluster. The credentials you use for that are used once and are never stored. After the machine has joined, SSH access to it plays no further part.
- A gigabit switch and fixed (static) network addresses for your machines are recommended, though not required, so the cluster’s machines don’t unexpectedly change address later.
Operating system
Every machine — master and workers alike — runs the same Ubuntu Server release (ARM64, or x86-64 to match whichever architecture you chose above). The master can be set up two ways, covered next; workers get a plain, unmodified install, and everything else about joining them happens from the panel.
What’s next
Continue to Install the master once your hardware and network match this list.