From 41dfd195a1384e06d274d473a7e094d7bc7abfc0 Mon Sep 17 00:00:00 2001 From: ahmza Date: Thu, 3 Sep 2026 04:01:12 +0100 Subject: [PATCH] Align 09-growing-up with actual control-plane/worker split --- docs/09-growing-up.md | 47 ++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/docs/09-growing-up.md b/docs/09-growing-up.md index 05b7644..11c2866 100644 --- a/docs/09-growing-up.md +++ b/docs/09-growing-up.md @@ -7,24 +7,43 @@ for you; each is its own project once you're ready. ## More nodes -Your three nodes already give you real resilience — losing any one still -leaves a majority of control-plane voters (see -[`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md#three-nodes-each-both-control-plane-and-worker)) -and, once Longhorn has real volumes, a replica of your data likely -survives too. Growing further is about *capacity*, not fault tolerance you -don't already have — so beyond this point, add plain **worker** nodes, not -more control-plane ones: +This cluster already separates roles — three Raspberry Pi control planes +(`talos-455-i3b`, `talos-9xy-iuk`, `talos-k1b-7j5`) and two Proxmox +workers (`talos-rss-v5l` on Gimli, `talos-vba-ood` on Titus; see +[`docs/network.md`](network.md) for current addresses). Losing any one +control plane still leaves a majority of etcd voters, and losing either +worker still leaves one healthy Longhorn replica of any volume that had +data on it. Growing further is about *capacity*, not fault tolerance you +don't already have — so beyond this point, add another plain **worker**, +not a fourth control plane. -1. Boot a new machine from the same custom Talos ISO as the first three - (see [`docs/01-prerequisites.md`](01-prerequisites.md)). -2. Apply the **worker** config instead of the control-plane one — you - already have `_out/worker.yaml` from - [`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md), unused until now: +1. Boot the new machine from a Talos image matching its own architecture + — `rpi_generic` (arm64) for another Raspberry Pi, or the amd64 metal + image for another x86 machine/VM. Both custom schematics already exist + for this cluster — see [`talos/patch-controlplane.yaml`](../talos/patch-controlplane.yaml) + and [`talos/patch-worker.yaml`](../talos/patch-worker.yaml) for the + exact installer image references, and + [`docs/01-prerequisites.md`](01-prerequisites.md) for building a new one + if this is a genuinely new architecture/extension set. +2. Generate (or reuse, if unchanged) a worker config with both + `talos/patch-worker.yaml` and `talos/patch-longhorn.yaml` applied, then + apply it to the new node: ```sh talosctl apply-config --insecure --nodes --file _out/worker.yaml ``` -3. `kubectl get nodes` should show a fourth node shortly after, without - the `control-plane` role. +3. If this node will also provide Longhorn storage, give it its own + dedicated data disk sized to fit `talos/patch-longhorn.yaml`'s + `minSize`, and label it the same way + [`talos/patch-worker.yaml`](../talos/patch-worker.yaml) labels the + existing two workers — `node.longhorn.io/create-default-disk=true` — + or Longhorn will never offer it a disk. +4. `kubectl get nodes` should show the new node shortly after, without the + `control-plane` role. With a third storage-providing worker, consider + raising Longhorn's `defaultReplicaCount` and + `persistence.defaultClassReplicaCount` in + [`apps/longhorn/values.yaml`](../apps/longhorn/values.yaml) from `2` to + `3` — see [`docs/06-longhorn.md`](06-longhorn.md) for why both settings + have to move together. ### Why not a fourth control-plane node