ser8: join kai-server k3s cluster as a worker node (warm-standby promotion later) #258

Closed
opened 2026-06-07 05:20:11 +00:00 by coilysiren · 0 comments
Owner

Goal

Join the Beelink SER8 (ser8, the home-2 warm-standby / DR box, see machine-kai-ser8 skill) to kai-server's k3s cluster as a plain worker node now, and promote it to its full cross-site warm-standby role later (per #99). Running it as a worker first is the low-friction incremental step: it delivers capacity immediately and does not conflict with the standby role, since promotion is an additive re-role (stop the agent, restore a snapshot, start k3s server).

State at filing (2026-06-06)

  • ser8 is on the tailnet (MagicDNS ser8, no kai- prefix), reachable; tailnet IP/FQDN stashed at /coilysiren/ser8/tailnet-{ip,fqdn}.
  • kai-server k3s: v1.32.3+k3s1, datastore sqlite/kine (no embedded etcd). Irrelevant for adding an agent; matters only for the future snapshot-ship design.
  • kai-server server flags (from scripts/k3s-start.sh): --flannel-iface=tailscale0, --node-ip=<tailnet ip>. The agent must match: --flannel-iface tailscale0 --node-ip <ser8 tailnet ip>.
  • ser8 has native IPv6 + no IPv4 LAN lease, so IPv4 reaches it only over tailscale0 — flannel-iface tailscale0 sidesteps that cleanly.
  • ser8 ↔ kai-server currently have no direct tailnet path (DERP-relayed via "sfo", ~29ms). Flannel-over-tailscale works relayed, just adds latency. Expected once truly cross-site at home-2.

Plan

  • Pin the agent to the server's k3s version (INSTALL_K3S_VERSION=v1.32.3+k3s1).
  • Join with K3S_URL=https://<kai-server tailnet ip>:6443, K3S_TOKEN=<node-token>, --node-ip <ser8 tailnet ip> --flannel-iface tailscale0.
  • Script: scripts/k3s-join-worker.sh (run on the joining node, fetches the node-token over ssh so it never lands in chat or a checked-in file).
  • Verify: ser8 shows Ready in k3s kubectl get nodes -o wide.

Out of scope (tracked separately under #99 follow-ups)

Snapshot-ship automation, promote runbook, orchestrator failover, measured RTO/RPO, game-server save sync.

## Goal Join the Beelink SER8 (`ser8`, the home-2 warm-standby / DR box, see `machine-kai-ser8` skill) to kai-server's k3s cluster as a **plain worker node now**, and promote it to its full cross-site warm-standby role later (per #99). Running it as a worker first is the low-friction incremental step: it delivers capacity immediately and does not conflict with the standby role, since promotion is an additive re-role (stop the agent, restore a snapshot, start `k3s server`). ## State at filing (2026-06-06) - `ser8` is on the tailnet (MagicDNS `ser8`, no `kai-` prefix), reachable; tailnet IP/FQDN stashed at `/coilysiren/ser8/tailnet-{ip,fqdn}`. - kai-server k3s: `v1.32.3+k3s1`, datastore **sqlite/kine** (no embedded etcd). Irrelevant for adding an agent; matters only for the future snapshot-ship design. - kai-server server flags (from `scripts/k3s-start.sh`): `--flannel-iface=tailscale0`, `--node-ip=<tailnet ip>`. The agent must match: `--flannel-iface tailscale0 --node-ip <ser8 tailnet ip>`. - ser8 has native IPv6 + **no IPv4 LAN lease**, so IPv4 reaches it only over `tailscale0` — flannel-iface `tailscale0` sidesteps that cleanly. - ser8 ↔ kai-server currently have **no direct tailnet path** (DERP-relayed via "sfo", ~29ms). Flannel-over-tailscale works relayed, just adds latency. Expected once truly cross-site at home-2. ## Plan - Pin the agent to the server's k3s version (`INSTALL_K3S_VERSION=v1.32.3+k3s1`). - Join with `K3S_URL=https://<kai-server tailnet ip>:6443`, `K3S_TOKEN=<node-token>`, `--node-ip <ser8 tailnet ip> --flannel-iface tailscale0`. - Script: `scripts/k3s-join-worker.sh` (run on the joining node, fetches the node-token over ssh so it never lands in chat or a checked-in file). - Verify: `ser8` shows `Ready` in `k3s kubectl get nodes -o wide`. ## Out of scope (tracked separately under #99 follow-ups) Snapshot-ship automation, promote runbook, orchestrator failover, measured RTO/RPO, game-server save sync.
Sign in to join this conversation.
No description provided.