ahmza.com/k8s-starter-pack
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align 09-growing-up with actual control-plane/worker split

Browse Source
This commit is contained in:
ahmza
2026-09-03 04:01:12 +01:00
parent c34b58e0b2
commit 41dfd195a1
1 changed files with 33 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/09-growing-up.md
+33 -14
View File
@@ -7,24 +7,43 @@ for you; each is its own project once you're ready.
## More nodes ## More nodes
Your three nodes already give you real resilience — losing any one still This cluster already separates roles — three Raspberry Pi control planes
leaves a majority of control-plane voters (see (`talos-455-i3b`, `talos-9xy-iuk`, `talos-k1b-7j5`) and two Proxmox
[`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md#three-nodes-each-both-control-plane-and-worker)) workers (`talos-rss-v5l` on Gimli, `talos-vba-ood` on Titus; see
and, once Longhorn has real volumes, a replica of your data likely [`docs/network.md`](network.md) for current addresses). Losing any one
survives too. Growing further is about *capacity*, not fault tolerance you control plane still leaves a majority of etcd voters, and losing either
don't already have — so beyond this point, add plain **worker** nodes, not worker still leaves one healthy Longhorn replica of any volume that had
more control-plane ones: 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 1. Boot the new machine from a Talos image matching its own architecture
(see [`docs/01-prerequisites.md`](01-prerequisites.md)). — `rpi_generic` (arm64) for another Raspberry Pi, or the amd64 metal
2. Apply the **worker** config instead of the control-plane one — you image for another x86 machine/VM. Both custom schematics already exist
already have `_out/worker.yaml` from for this cluster — see [`talos/patch-controlplane.yaml`](../talos/patch-controlplane.yaml)
[`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md), unused until now: 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 ```sh
talosctl apply-config --insecure --nodes <NEW_NODE_IP> --file _out/worker.yaml talosctl apply-config --insecure --nodes <NEW_NODE_IP> --file _out/worker.yaml
``` ```
3. `kubectl get nodes` should show a fourth node shortly after, without 3. If this node will also provide Longhorn storage, give it its own
the `control-plane` role. 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 ### Why not a fourth control-plane node