Skip to content

Hardware Inventory

The hostnames follow the Invincible series — see character category. deborah was previously orangepi5plus.

Data measured with playbook-discovery.yml. Where the nominal value differs from the measured, the Measured column is the source of truth for planning.

invincible x86_64
Lenovo M920q · i7-8700T 6c/12t
RAM: 15.5 GB
Static IP: 192.168.20.6
Incus: leader · K3s: Worker (agent)
oliver x86_64
Lenovo M700 · i3-6100T 2c/4t
RAM: 7.7 GB
Static IP: 192.168.20.7
Incus: Member (manual scheduler) · K3s: Worker (agent)
deborah ARM64
Orange Pi 5 Plus · RK3588 8c
RAM: 31.0 GB
Static IP: 192.168.20.5
Incus: Member (arm64 group) · K3s: Control-plane (server)

Nominal specs vs measured

Measured on the nodes themselves with playbook-discovery.yml (and verified with lscpu, free, dmidecode, and lsblk); RAM is given in GiB, as reported by discovery: invincible is the M920q with i7-8700T and 15.5 GB, and oliver is the M700 with i3-6100T and 7.7 GB.

IP Scheme

Concept invincible oliver deborah
SSH IP today (ansible_host) 192.168.20.6 192.168.20.7 192.168.20.5
Static IP in br0 192.168.20.6 192.168.20.7 192.168.20.5
Physical interface → bridge eno2 eno1 enP4p65s0

After playbook-set-static-ip.yml, update ansible_host in inventory.ini if the connection IP changed.

Storage and I/O

Node Main Disk 4k Write (dd/fio)
invincible Kingston SA400 224GB 78.4 MB/s
oliver TECLAST 120GB SSD 73.9 MB/s
deborah eMMC mmcblk1 233GB (root) 59.5 MB/s

Test: dd of 40 MB in 4k blocks with direct write (oflag=direct). The NVMe WDC 250GB (nvme0n1) of deborah is not detected: lsblk and lspci do not see it and dmesg says rk-pcie … PCIe Link Fail (the slot link does not come up).

RAM Budget (recalculated)

  • invincible (15.5 GB): K3s (lightweight Kubernetes distribution) agent + Argo CD controller + Incus leader. It is the x86 node with the most margin and the fastest disk: it supports CAPN (Cluster API Provider for Incus) management and Longhorn simultaneously.
  • oliver (7.7 GB): K3s agent (CoreDNS, metrics-server) + Incus in scheduler.instance manual. RAM adjusted: that's why it remains a light node and, in the design, outside of Longhorn (see Longhorn v1).
  • deborah (31 GB): K3s control plane + BIND (role bind_dns) + Ollama on demand (role ollama_ondemand, group llm_nodes, alongside invincible and oliver): it only uses RAM while responding and releases it about 5 minutes later (see Local AI Assistant). Root on eMMC; the NVMe (SSD via PCIe) is not detected (see Storage and I/O).

Decision: control plane on deborah

Moving the control plane is only an option

The control plane stays on deborah. If it ever makes sense to move it to another node (for example, to oliver), the procedure is in Moving the control plane; it is not planned today.

Status: the API server responds on 192.168.20.5:6443 (deborah). Workers on invincible (192.168.20.6) and oliver (192.168.20.7). Installed with K3s v1.36.5+k3s1 (k3s_install.core.version); afterwards the SUC (System Upgrade Controller) updates it automatically (Updating K3s). Actual version: kubectl get nodes.

Trade-off Analysis
A: deborah chosen
31 GB RAM, ARM64 (root on eMMC; NVMe not detected)
SBC; thermal throttling; extra services on the same node
B: invincible
I/O 78.4 MB/s (the best measured); 15.5 GB RAM; i7-8700T
It is the Incus leader; costly control plane migration
C: oliver
Node already reserved for quorum
Only 7.7 GB RAM; I/O 73.9 MB/s

Discovery note: without NVMe, deborah measures the lowest I/O (59.5 MB/s on eMMC) and invincible the highest (78.4 MB/s); the report itself suggests considering invincible as the control plane. The decision to keep deborah is maintained until fsync latency (fio) is measured, which is what matters for etcd.

deborah after reboot

If after a reboot deborah has the k3s binary but no active service or port :6443, check sudo systemctl enable --now k3s and the logs (sudo journalctl -u k3s -n 50).

See also