Files

T

Maxwell MorrisandClaude Sonnet 5 110bd97cca Move to a three-node cluster with a Talos VIP; add Longhorn

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>

2026-08-22 18:25:38 +01:00

2.5 KiB

Raw Blame History

03 — Installing Argo CD

Your cluster is alive but empty — it can run containers, but nothing is telling it to run anything yet. This doc installs Argo CD, the piece that watches Git and does that telling from now on.

Why this one step is imperative

Everything else in this repo — every app, every future addition — gets deployed by Argo CD, driven from Git. Argo CD itself is the one exception: something has to exist in the cluster before it can start reading Git, so installing it can't itself be a GitOps-managed step. This is normal, and every GitOps setup has some version of this same bootstrap moment. We install it the straightforward way the Argo CD project documents — one kubectl apply of their maintained manifest bundle — rather than adding an extra tool (Helm, an operator) just to install the GitOps tool itself.

What you're installing

Argo CD is itself a set of things running inside your cluster: an API server, a piece that watches Git repos, a piece that computes diffs against the live cluster, and a UI. You're about to install all of it with one command, into its own argocd namespace, so it stays cleanly separated from the apps it will go on to manage.

Steps

Exact commands: argocd/README.md. Summary of what each stage does:

Install. kubectl apply the official manifest bundle into a new argocd namespace. This creates Argo CD's own pods and a handful of CRDs (see docs/glossary.md) — the most important being Application, the resource type you'll use for every app from here on, including the demo app and the app-of-apps.
Get the initial admin password. Auto-generated on first install and stored as a Kubernetes Secret.
Reach it. Port-forward the Argo CD UI/API to your local machine and log in with the argocd CLI (and optionally, a browser).
Apply the app-of-apps. This is the moment the GitOps loop actually starts — see docs/04-app-of-apps.md next.

Ask Claude: "why is a port-forward good enough for now, and what would I need instead to reach this Argo CD from somewhere other than my own machine?" — a preview of the Ingress topic in docs/09-growing-up.md.

Checklist

Argo CD pods all Running/Ready in the argocd namespace
Initial admin password retrieved
Logged in via argocd login (CLI) and/or the UI in a browser

Once you're logged in, continue to docs/04-app-of-apps.md.

2.5 KiB Raw Blame History