mirror of
https://github.com/RWejlgaard/pez-infra.git
synced 2026-07-04 15:46:16 +00:00
Provisions the substrate for the kube-proxmox Flux cluster on london-a: a control-plane VM (k3s installed later by the k3s_server Ansible role) and a worker template that kproximate clones to autoscale. Wires a bpg/proxmox provider (api token + SSH to root@london-a for snippet upload) into the root module. Workers auto-join k3s via a cloud-init snippet; the join token is a two-phase apply (see proxmox/README.md).
1.7 KiB
1.7 KiB
proxmox
Provisions the Kubernetes cluster substrate on the london-a Proxmox node for the kube-proxmox Flux cluster:
- a control-plane VM (
k3s-server,192.168.100.10) — plain Debian; the Ansiblek3s_serverrole installs k3s onto it. - a worker template (
k3s-agent-template) — cloned by kproximate; its cloud-init installs the k3s agent and joins the cluster on first boot.
Required secrets
Add to terraform/secrets.enc.yaml (sops terraform/secrets.enc.yaml):
| Key | Value |
|---|---|
proxmox_api_token |
root@pam!kube=<token-secret> |
k3s_node_token |
k3s agent join token (phase 2 — see below) |
The provider also SSHes to root@london-a (over Tailscale) to upload the
cloud-init snippet, so the apply environment needs that key in its agent.
Two-phase bootstrap
The worker template bakes the k3s join token into cloud-init, but that token only exists once the control plane is up:
- Phase 1 — apply with
k3s_node_token = "". Creates the control-plane VM and the (not-yet-joinable) template. - Run the Ansible
k3s_serverrole; it installs k3s and writes the node token to SOPS. - Phase 2 — set
k3s_node_tokenand re-apply. The template is rebuilt with a working join script; kproximate clones from it.
Notes
- Workers get addresses via DHCP on the cluster bridge — ensure the
192.168.100.0/24segment has a DHCP range, or switch the template to static addressing managed by kproximate. disk_datastore_iddefaults tolocal-lvmandsnippet_datastore_idtolocal; override if london-a uses different storage (e.g. thehddCIFS mount).