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>
61 lines
2.7 KiB
YAML
61 lines
2.7 KiB
YAML
# 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.
|
|
#
|
|
# 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
|
|
# standalone Talos resource that doesn't live inside `machine:`/`cluster:`
|
|
# at all.
|
|
#
|
|
# --- Document 1: mount the volume into the kubelet's view ---
|
|
# Talos runs the kubelet in its own isolated mount namespace. Without this,
|
|
# a volume mounted at /var/mnt/longhorn on the node itself would be
|
|
# invisible to any Pod using a hostPath-style mount there — which is
|
|
# exactly how Longhorn's own manager and engine Pods access node storage.
|
|
# This bind-mounts that same path into the kubelet's namespace so Pods can
|
|
# actually see it. `rshared` matters specifically: it lets mounts Longhorn
|
|
# creates later *underneath* this path (one per volume) propagate back out
|
|
# to the host, instead of being invisible outside the container that made
|
|
# them.
|
|
#
|
|
# --- Document 2: UserVolumeConfig ---
|
|
# 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.
|
|
# `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).
|
|
#
|
|
# The `name: longhorn` below is what determines the mount path Talos uses
|
|
# — user volumes are always mounted at /var/mnt/<name>, which is why
|
|
# Document 1 above and apps/longhorn/values.yaml both hardcode
|
|
# /var/mnt/longhorn. Renaming this would mean updating both.
|
|
#
|
|
# >> Ask Claude: "how do I find out which of my disks Talos will actually
|
|
# pick for this?" before you boot for real — worth confirming on your
|
|
# specific hardware rather than assuming.
|
|
machine:
|
|
kubelet:
|
|
extraMounts:
|
|
- destination: /var/mnt/longhorn
|
|
type: bind
|
|
source: /var/mnt/longhorn
|
|
options:
|
|
- bind
|
|
- rshared
|
|
- rw
|
|
---
|
|
apiVersion: v1alpha1
|
|
kind: UserVolumeConfig
|
|
name: longhorn
|
|
provisioning:
|
|
diskSelector:
|
|
match: "!system_disk"
|
|
minSize: 900GiB
|
|
grow: false
|