Files
k8s-starter-pack/docs/08-growing-up.md
T
Maxwell MorrisandClaude Sonnet 5 92c3ad3191 Initial commit: GitOps Starter Pack
A teaching-first, single-cluster GitOps setup: Talos Linux + Argo CD with
an app-of-apps layout, MetalLB pre-installed for real LoadBalancer IPs on
bare metal, a demo app, and a progressive docs/ walkthrough with a
CLAUDE.md tutor persona and guided bootstrap checklist.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 17:30:45 +01:00

4.3 KiB

08 — Growing up: what to add next

Everything up to here is deliberately minimal — enough to understand the whole loop, nothing more. This doc is a map of the natural next steps, each with why you'd want it and roughly what it involves. None of it is built for you; each is its own project once you're ready.

More nodes

Right now, one machine is both control plane and worker (allowSchedulingOnControlPlanes: true in talos/patch-controlplane.yaml). That's a single point of failure: if that machine dies, the cluster is gone.

To grow beyond it:

  1. Boot a second machine from the Talos ISO, same as the first.
  2. Generate a worker config instead of a control-plane one — you already have _out/worker.yaml from docs/02-talos-bootstrap.md, unused until now.
  3. talosctl apply-config --insecure --nodes <NEW_NODE_IP> --file _out/worker.yaml
  4. kubectl get nodes should show two nodes shortly after.

For real resilience against a control-plane node failing (not just adding worker capacity), you'd want an odd number of control-plane nodes — 3 is the normal minimum — because etcd (the cluster's data store) uses majority voting to agree on state, and majority voting needs an odd number to avoid ties. That's a bigger step than this doc covers in detail; ask Claude when you're actually ready to take it.

Ingress

Right now, thanks to MetalLB (docs/05-metallb.md), the demo app gets its own dedicated IP address (see apps/demo/service.yaml). That's a real improvement over NodePort, but it doesn't scale past a handful of apps either: every app still needs its own IP address out of a pool that's only so big, and there's no way to route by hostname (app1.example.com vs app2.example.com sharing one IP on port 443).

An Ingress controller is itself just another app you'd deploy the same way as anything else in this repo (see docs/07-adding-new-apps.md) — commonly as a Helm-based app, since most ingress controllers are distributed that way, same as MetalLB. It typically sits behind one single MetalLB LoadBalancer Service (one IP, total, for every app), and you add an Ingress resource per app instead of giving each one its own LoadBalancer Service — trading "one IP per app" for "one IP, many hostnames."

cert-manager

Once you have Ingress and real hostnames, you'll want HTTPS. cert-manager is the standard tool for this — it watches for certificate requests and automatically obtains and renews them (commonly via Let's Encrypt). Also just another app in this repo's structure once you get there.

Secrets management

This repo is public. Never commit a plaintext secret, credential, token, or private key to it — anyone can read your Git history, forever, even if you delete the file in a later commit.

Kubernetes' own Secret resource does not encrypt anything — it just base64-encodes data, which is not encryption, only encoding (trivially reversible by anyone). None of the manifests in this repo need secrets yet, which is exactly why this hasn't come up so far. When you add something that does (a database password, an API key), you need one of:

  • Sealed Secrets — encrypts a secret using a key that only your cluster holds, producing a SealedSecret file that's safe to commit; the cluster decrypts it into a normal Secret on the fly.
  • SOPS (often paired with Argo CD via a plugin) — encrypts values inside a normal-looking YAML file using a key from a system like age or a cloud KMS, decrypted at sync time.

Either is a reasonable choice; don't improvise your own approach. Ask Claude to walk you through setting one up when you have a real secret to manage — it's a short, well-trodden path once you're at that point.

Ask Claude: if you're about to commit anything you're even slightly unsure about, paste it (or describe it) and ask first. Cheaper than a git filter-branch later.

Where to go from here

You've now seen the whole shape: Talos underneath, Argo CD watching Git, app-of-apps organizing what it manages. Everything in this doc is more of the same pattern — a new app, a new file, a push. Pick whichever expansion is actually useful to you and start there.