The four machines
CPU, memory, GPU and role for every node, from the capacity the API server reports.
nvidia
kubernetesValues below are status.capacity from the API server, not the marketing sheet, so
they are what Kubernetes will actually schedule against.
| node | kind | cpu | memory | gpu | site |
|---|---|---|---|---|---|
baremetal-controlplane |
physical | Ryzen 9 9950X, 16C/32T | 60.4 GiB | - | svt |
baremetal-worker1 |
physical | Ryzen 9 5950X, 16C/32T | 62.7 GiB | 3 x GA107 | svt |
oracle-controlplane |
OCI VM | 4 vCPU, Ampere | 23.4 GiB | - | eu-frankfurt-1 |
nix-desktop-controlplane |
libvirt VM | 4 vCPU, Ryzen 5 8600G host | 5.8 GiB | - | home |
All four run Talos v1.14.4, amd64 except oracle-controlplane, which is arm64.
Three nodes are control-plane, one is a plain worker. The desktop VM is cordoned
(SchedulingDisabled) and holds only etcd quorum duty, because 5.8 GiB is not enough
to be useful and the noise of a desktop is not worth the capacity.
The GPU node
baremetal-worker1 carries three GA107 cards (RTX 3050 6 GB class) exposed as
nvidia.com/gpu through the GPU operator. Three cards on one machine is why model
serving and image generation run there and not elsewhere.
The odd node out
oracle-controlplane is the only arm64 machine and the only one with a public
address. Both facts leak into manifests: anything with a prebuilt amd64 image pins
the architecture, and anything that must be reachable from the internet has to land
where the OCI NAT forwards.
Local routers
The svt machines sit behind a GL.iNet Flint 3 running OpenWrt, which is also a
Tailscale subnet router and a NetBird peer. The desktop VM sits behind libvirt on
192.168.122.0/24. Neither router is managed by Kubernetes; both are Ansible
playbooks in this repository.