whentimeslows/home-services
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Configure Talos nodes for Longhorn storage
Deploy home services / deploy-nas1 (push) Has been cancelled
Details
Deploy home services / deploy-rhel1 (push) Has been cancelled
Details

Browse Source 
Add the Talos extension image and dedicated user volume configuration, point Longhorn at the mounted disk, and document rebuild and rolling-upgrade steps.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Scott Sorell
2026-10-09 11:22:06 -06:00
parent c351a1c3d6
commit e3c51bb3ae
9 changed files with 97 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
GITOPS.md
+18 -5
View File
@@ -6,28 +6,41 @@ Terraform owns Talos machine configuration, cluster bootstrap, and the Argo CD H
## First bootstrap
1. Confirm Talos `v1.14.0`, a supported Kubernetes version, the control-plane endpoint, the VM install disk, and the `nodes` list. Mark exactly one control-plane node as `bootstrap = true`.
1. Confirm Talos `v1.14.0`, the matching `talos_installer_image` (including `iscsi-tools` and `util-linux-tools`), a supported Kubernetes version, the control-plane endpoint, the VM install disk, a dedicated `/dev/vdb` Longhorn data disk on every storage node, and the `nodes` list. Mark exactly one control-plane node as `bootstrap = true`.
2. Confirm the Gitea URL is reachable from the cluster and its certificate is trusted.
3. Run Terraform from `terraform/` using a local variable file that is not committed.
4. Verify the `argocd` namespace and Argo CD pods.
5. Verify the `gitea-repository` Secret has the Argo CD repository label and does not expose credentials in Git.
6. Apply `bootstrap/applicationsets/` once.
6. Apply `terraform/longhorn-user-volume.yaml` to each storage node with `talosctl patch machineconfig`, then reboot nodes one at a time (worker first) and verify they rejoin with the volume mounted at `/var/mnt/longhorn`:
```bash
talosctl patch machineconfig --endpoints 10.0.0.246 --nodes 10.0.0.246 --patch @terraform/longhorn-user-volume.yaml
talosctl patch machineconfig --endpoints 10.0.0.99 --nodes 10.0.0.99 --patch @terraform/longhorn-user-volume.yaml
talosctl reboot --endpoints 10.0.0.246 --nodes 10.0.0.246 --wait
talosctl health --endpoints 10.0.0.99 --nodes 10.0.0.99,10.0.0.246
talosctl reboot --endpoints 10.0.0.99 --nodes 10.0.0.99 --wait
talosctl health --endpoints 10.0.0.99 --nodes 10.0.0.99,10.0.0.246
```
7. Apply `bootstrap/applicationsets/` once.
Terraform generates one machine-secrets bundle, renders one machine configuration per role, applies the matching configuration to every node, and bootstraps only the selected control-plane node. For more than one control-plane node, `cluster_endpoint` must resolve to a stable VIP or load balancer rather than an individual node address.
The Talos installer image is generated from `terraform/talos-image-schematic.yaml`; keep its Image Factory schematic ID and Talos version aligned in the Terraform default and this runbook. The extra Longhorn data disk is provisioned separately using the checked-in UserVolumeConfig because it is a Talos resource, not a Kubernetes workload.
## Talos 1.13 to 1.14 upgrade
Talos 1.14 uses the Image Factory installer image. The old image `ghcr.io/siderolabs/installer:v1.14.0` is not published and returns `NotFound`. For these amd64 KVM nodes, use the configured schematic:
```bash
export TALOSCONFIG="$HOME/.talos/home-services/talosconfig"
export TALOS_INSTALLER_IMAGE="factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.0"
export TALOS_INSTALLER_IMAGE="factory.talos.dev/metal-installer/613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245:v1.14.0"
```
Upgrade one node at a time, worker first:
```bash
talosctl upgrade --endpoints 10.0.0.246 --nodes 10.0.0.246 --image "$TALOS_INSTALLER_IMAGE" --wait
talosctl upgrade --endpoints 10.0.0.246 --nodes 10.0.0.246 --image "$TALOS_INSTALLER_IMAGE" --drain=false --wait
talosctl version --endpoints 10.0.0.246 --nodes 10.0.0.246
talosctl upgrade --endpoints 10.0.0.99 --nodes 10.0.0.99 --image "$TALOS_INSTALLER_IMAGE" --drain=false --wait
@@ -35,7 +48,7 @@ talosctl version --endpoints 10.0.0.99 --nodes 10.0.0.99
talosctl health --endpoints 10.0.0.99 --nodes 10.0.0.99,10.0.0.246
```
Set `--endpoints` to the same address as `--nodes` for each upgrade. This prevents Talosctl from attempting request forwarding through the other node during the version-compatibility check. The control-plane upgrade uses `--drain=false` because this single-control-plane cluster cannot safely drain through a Kubernetes kubeconfig during the Talos transition.
Set `--endpoints` to the same address as `--nodes` for each upgrade. This prevents Talosctl from attempting request forwarding through the other node during the version-compatibility check. Both upgrades use `--drain=false`: there is only one schedulable worker for Argo CD, and the single-control-plane cluster cannot safely drain through a Kubernetes kubeconfig during the Talos transition.
After both nodes report 1.14, set `talos_version = "v1.14.0"` in `terraform.tfvars`, then run `terraform plan` and `terraform apply` to reconcile the generated machine configurations and GitOps workloads. Do not reset or recreate the VMs during an in-place upgrade.