Maxwell MorrisandClaude Sonnet 5
110bd97cca
Every node is now both control plane and worker, giving real tolerance for losing any single machine (etcd quorum needs 3, not 1). A Talos VIP gives the cluster one stable address regardless of which node answers. Also pre-installs Longhorn for replicated storage, backed by a Talos UserVolume on each node's second disk (>=900GB, non-system) rather than the default path — mirroring the pattern from the homescale repo. Docs renumbered to make room for 06-longhorn.md; checklist, glossary, network map, and CLAUDE.md's guided-bootstrap instructions updated to match, including asking the user for node IPs, VIP, and disk info before generating any Talos config. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
44 lines
2.2 KiB
YAML
44 lines
2.2 KiB
YAML
# A patch applied on top of the controlplane.yaml that `talosctl gen config`
|
|
# 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.
|
|
#
|
|
# >> 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.
|
|
#
|
|
# --- vip ---
|
|
# With three control-plane nodes, "the cluster's API server" isn't one
|
|
# fixed machine anymore — it's whichever of the three happen to be up.
|
|
# Talos's VIP (Virtual IP) feature solves this: the three nodes
|
|
# continuously elect one of themselves to answer on this one shared
|
|
# address, and re-elect within seconds if that node goes down. Point
|
|
# everything that talks to the cluster (talosctl, kubectl, this repo's
|
|
# Application manifests) at the VIP, never at one node's own address —
|
|
# that's what makes losing any single node a non-event instead of an
|
|
# outage.
|
|
#
|
|
# Replace both the interface name and the IP below with your real values
|
|
# before generating config — see docs/02-talos-bootstrap.md.
|
|
#
|
|
# >> Ask Claude to help you pick the VIP address — like the MetalLB pool in
|
|
# docs/05-metallb.md, it has to be a real, unused address on your LAN,
|
|
# outside your DHCP range.
|
|
cluster:
|
|
allowSchedulingOnControlPlanes: true
|
|
machine:
|
|
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)
|
|
dhcp: true
|
|
vip:
|
|
ip: 192.168.1.239 # EDIT ME — replace with your chosen VIP address
|