Adapt Talos config for five-node mixed architecture cluster

docs/network.md

@@ -13,20 +13,24 @@ assigned or changed, so you (or Claude) never have to reverse-engineer
 > instruction that tells Claude to do this on its own when it makes such a
 > change itself.
 
-## The three nodes and the VIP
+## The five nodes and the VIP
 
 None of these are from the MetalLB pool below — they're the machines
-themselves and the shared address Talos elects between them. Set in
+themselves and the shared address Talos elects between the three control-plane
-[`talos/README.md`](../talos/README.md); see
+nodes. Set in [`talos/README.md`](../talos/README.md); see
 [`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md) for what the VIP is
-and why it's separate from any one node's address.
+and why it's separate from any one node's address. Port 6443 is the Kubernetes
+API on control-plane nodes; port 50000 is Talos's TLS-protected management API
+on every node.
 
-| Address | What | Port | URL |
+| Address | What | Port(s) | URL(s) |
 |---|---|---|---|
-| `EDIT ME` | Node 1 | 6443 | `https://EDIT ME:6443` |
+| `10.10.10.200` | `talos-m4x-o87` — control plane (Raspberry Pi 4) | 6443, 50000 | `https://10.10.10.200:6443`, `https://10.10.10.200:50000` |
-| `EDIT ME` | Node 2 | 6443 | `https://EDIT ME:6443` |
+| `10.10.10.201` | `talos-woj-ep6` — control plane (Raspberry Pi 4) | 6443, 50000 | `https://10.10.10.201:6443`, `https://10.10.10.201:50000` |
-| `EDIT ME` | Node 3 | 6443 | `https://EDIT ME:6443` |
+| `10.10.10.202` | `talos-s2g-djt` — control plane (Raspberry Pi 4) | 6443, 50000 | `https://10.10.10.202:6443`, `https://10.10.10.202:50000` |
-| `EDIT ME` | Cluster VIP (use this one, not a node's own address) | 6443 | `https://EDIT ME:6443` |
+| `10.10.10.203` | `worker01` — worker (Proxmox VM) | 50000 | `https://10.10.10.203:50000` |
+| `10.10.10.204` | `worker02` — worker (Proxmox VM) | 50000 | `https://10.10.10.204:50000` |
+| `10.10.10.210` | Cluster VIP (use this one, not a node's own address) | 6443 | `https://10.10.10.210:6443` |
 
 ## MetalLB pool
 

talos/patch-controlplane.yaml

@@ -2,18 +2,19 @@
 # produces (see talos/README.md and docs/02-talos-bootstrap.md for the full
 # command). Applied identically to all three control-plane nodes.
 #
-# --- allowSchedulingOnControlPlanes ---
+# --- control-plane-only scheduling ---
-# Talos's generated defaults assume control-plane nodes only run the
+# These Raspberry Pis run the Kubernetes API, scheduler, and etcd, but not
-# Kubernetes control plane itself (API server, scheduler, etcd, etc.) and
+# ordinary application Pods. Keeping workloads on the two dedicated workers
-# never your actual workloads — normal practice, so a workload crashing
+# prevents a busy or broken app from competing with the cluster's own control
-# never has a chance to take the control plane down with it. This repo's
+# plane. `false` is Talos's normal default, repeated explicitly because this
-# three nodes are deliberately both control plane AND worker at once (no
+# five-node layout depends on that separation.
-# separate worker nodes), to get real multi-node resilience without needing
-# more than three machines. This one field undoes the default restriction.
 #
-# >> Ask Claude: "why does Kubernetes normally keep workloads off control
+# --- install image ---
-#    plane nodes, and what am I giving up by turning that off here?" if you
+# All three control planes are Raspberry Pi 4 systems currently installed on
-#    want the reasoning before you turn it off.
+# their microSD (`mmcblk0`). The Image Factory schematic contains the
+# `rpi_generic` ARM64 overlay needed to boot this hardware. Keep this custom
+# installer reference during upgrades or the board-specific boot support may
+# be lost.
 #
 # --- vip ---
 # With three control-plane nodes, "the cluster's API server" isn't one
@@ -33,11 +34,17 @@
 #    docs/05-metallb.md, it has to be a real, unused address on your LAN,
 #    outside your DHCP range.
 cluster:
-  allowSchedulingOnControlPlanes: true
+  allowSchedulingOnControlPlanes: false
 machine:
+  install:
+    disk: /dev/mmcblk0
+    image: factory.talos.dev/metal-installer/ee21ef4a5ef808a9b7484cc0dda0f25075021691c8c09a276591eedb638ea1f9:v1.13.8
   network:
     interfaces:
-      - interface: eth0 # EDIT ME — match your node's real NIC name (`talosctl get links --insecure --nodes <NODE_IP>` from maintenance mode will show it)
+      # Raspberry Pi 4's built-in Ethernet interface is named `end0` by
+      # Talos. DHCP reservations keep .200-.202 stable while still letting
+      # DHCP supply the gateway and DNS settings.
+      - interface: end0
         dhcp: true
         vip:
-          ip: 192.168.1.239 # EDIT ME — replace with your chosen VIP address
+          ip: 10.10.10.210

talos/patch-longhorn.yaml

@@ -1,6 +1,7 @@
-# Prepares each node for Longhorn (apps/longhorn.yaml) — the storage layer
+# Prepares each dedicated worker for Longhorn (apps/longhorn.yaml) — the
-# this repo ships pre-installed. Applied identically to all three
+# storage layer this repo ships pre-installed. Applied to worker.yaml only;
-# control-plane nodes, alongside patch-controlplane.yaml.
+# the three Raspberry Pi control-plane nodes do not provide application
+# storage.
 #
 # This file has TWO documents (separated by `---`), because it's making two
 # different kinds of change: a patch to the normal machine config, and a
@@ -22,11 +23,10 @@
 # A Talos UserVolumeConfig tells Talos itself to find, format, and mount a
 # disk — no manual partitioning on your part. `diskSelector.match:
 # '!system_disk'` means "any disk that isn't the one Talos is installed
-# on" (never touches your OS disk), and `minSize: 900GiB` means "only
+# on" (never touches your OS disk), and `minSize: 300GiB` means "only
-# consider disks at least that large" — so if a node has more than one
+# consider disks at least that large." Each worker has one 350GiB data disk
-# extra disk, Talos won't accidentally pick a small one. Adjust `minSize`
+# and one 20GiB system disk, so this admits the intended data disk while
-# if your nodes' data disks are smaller than 900GiB; just make sure it's
+# rejecting the boot disk.
-# still large enough to exclude anything that *isn't* meant for Longhorn.
 # `grow: false` keeps the volume at its initial size even if the
 # underlying disk is later resized — deliberate here, so growing storage
 # is always a conscious decision (see docs/09-growing-up.md).
@@ -56,5 +56,5 @@ name: longhorn
 provisioning:
   diskSelector:
     match: "!system_disk"
-  minSize: 900GiB
+  minSize: 300GiB
   grow: false

talos/patch-worker.yaml

@@ -0,0 +1,25 @@
+# Applied to worker.yaml alongside patch-longhorn.yaml. These two workers are
+# amd64 Proxmox VMs; they run ordinary application Pods and provide Longhorn's
+# two independent storage replicas.
+#
+# `disk: /dev/sda` is the dedicated 20GiB Talos boot disk. Longhorn's 350GiB
+# disk is /dev/sdb and is selected separately by patch-longhorn.yaml. Naming
+# both roles explicitly prevents an installer or storage selector from
+# claiming the wrong virtual disk.
+#
+# The custom Image Factory installer contains Longhorn's `iscsi-tools` and
+# `util-linux-tools` extensions plus `qemu-guest-agent`. Keep this schematic
+# reference during future upgrades; switching to the stock installer would
+# silently remove those extensions.
+#
+# Both VMs use `ens18`. Their DHCP-reserved MAC addresses keep worker01 at
+# 10.10.10.203 and worker02 at 10.10.10.204 while DHCP supplies their gateway
+# and DNS settings.
+machine:
+  install:
+    disk: /dev/sda
+    image: factory.talos.dev/metal-installer/88d1f7a5c4f1d3aba7df787c448c1d3d008ed29cfb34af53fa0df4336a56040b:v1.13.8
+  network:
+    interfaces:
+      - interface: ens18
+        dhcp: true