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

Adapt Talos config for five-node mixed architecture cluster

Browse Source
This commit is contained in:
ahmza
2026-09-02 22:50:34 +01:00
parent 110bd97cca
commit a5ddf11992
4 changed files with 68 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/network.md
+13 -9
View File
@@ -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
[`talos/README.md`](../talos/README.md); see
themselves and the shared address Talos elects between the three control-plane
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` |
| `EDIT ME` | Node 2 | 6443 | `https://EDIT ME:6443` |
| `EDIT ME` | Node 3 | 6443 | `https://EDIT ME:6443` |
| `EDIT ME` | Cluster VIP (use this one, not a node's own address) | 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` |
| `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` |
| `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` |
| `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
+21 -14
View File
@@ -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
+9 -9
View File
@@ -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
+25
View File
@@ -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