Adapt Talos config for five-node mixed architecture cluster

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 ---
-# Talos's generated defaults assume control-plane nodes only run the
-# Kubernetes control plane itself (API server, scheduler, etcd, etc.) and
-# never your actual workloads — normal practice, so a workload crashing
-# never has a chance to take the control plane down with it. This repo's
-# three nodes are deliberately both control plane AND worker at once (no
-# separate worker nodes), to get real multi-node resilience without needing
-# more than three machines. This one field undoes the default restriction.
+# --- control-plane-only scheduling ---
+# These Raspberry Pis run the Kubernetes API, scheduler, and etcd, but not
+# ordinary application Pods. Keeping workloads on the two dedicated workers
+# prevents a busy or broken app from competing with the cluster's own control
+# plane. `false` is Talos's normal default, repeated explicitly because this
+# five-node layout depends on that separation.
 #
-# >> Ask Claude: "why does Kubernetes normally keep workloads off control
-#    plane nodes, and what am I giving up by turning that off here?" if you
-#    want the reasoning before you turn it off.
+# --- install image ---
+# All three control planes are Raspberry Pi 4 systems currently installed on
+# 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
-# this repo ships pre-installed. Applied identically to all three
-# control-plane nodes, alongside patch-controlplane.yaml.
+# Prepares each dedicated worker for Longhorn (apps/longhorn.yaml) — the
+# storage layer this repo ships pre-installed. Applied to worker.yaml only;
+# 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
-# consider disks at least that large" — so if a node has more than one
-# extra disk, Talos won't accidentally pick a small one. Adjust `minSize`
-# if your nodes' data disks are smaller than 900GiB; just make sure it's
-# still large enough to exclude anything that *isn't* meant for Longhorn.
+# on" (never touches your OS disk), and `minSize: 300GiB` means "only
+# consider disks at least that large." Each worker has one 350GiB data disk
+# and one 20GiB system disk, so this admits the intended data disk while
+# rejecting the boot disk.
 # `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