Previous version listed commands with light justification; this
explains the actual mechanism at each stage - qemu:///system vs
session, why pools mediate permissions, COW overlays, what cloud-init's
two data files are for, what each virt-install flag does, what a
kubeconfig actually contains, and (the deepest gap) what flux bootstrap
concretely does under the hood: the controllers/CRDs involved, what
GitRepository and Kustomization objects actually do on their reconcile
loops, why apps.yaml gets picked up automatically, and how the auth
Secret works - with kubectl/flux commands to go verify each claim
against the already-bootstrapped cluster rather than take it on faith.
Rename k8s's key from the custom k3s_homelab to the default
id_ed25519 - the custom name had no real justification (k8s is a
fresh account with nothing to collide with) and caused a real bug:
OpenSSH only auto-offers default-named keys, so ssh commands lacking
an explicit -i silently failed to authenticate. Also add the
never-actually-documented kubectl install step, and mkdir -p ~/.kube
before the first redirect into it, in both SETUP.md and QUICKSTART.md.
Debian's libvirt-daemon-system doesn't auto-create a default storage
pool (network exists but inactive) - added explicit pool-define/build/
start and net-start steps. Also fixed --cloud-init user-data=~/... not
expanding (tilde only expands at start of a shell word, not after =),
and noted why --os-variant may need to be an older release than the
actual image if osinfo-db is stale.
Disk images under k8s's home directory aren't readable by the
libvirt-qemu user that actually runs VMs under qemu:///system. Use
libvirt's own default storage pool (vol-create-as/vol-upload) instead,
so libvirtd handles file ownership rather than k8s directly, and pin
LIBVIRT_DEFAULT_URI=qemu:///system throughout.
