portal GitHub ↗

deployment artifact · arXiv:2603.23942

A high-availability
k3s cluster, driven
from one terminal.

portal packages the automation and operational docs behind the computing resources management layer in the paper — HA k3s over embedded etcd, GPU worker nodes, Tailscale + Flannel networking, and Rancher — operated entirely through cluster-ctl, a Rust TUI that talks to your nodes over plain SSH.

shell
$ cd cli && cargo run --release
MIT licensed / no Ansible, no Python runtime / SSH key + TOFU host-key pinning

Topology

What portal actually stands up

01 · control plane

Three HA masters

k3s control-plane nodes with embedded etcd. The first k3s_master in cluster.toml bootstraps the cluster with --cluster-init and doubles as the join endpoint of last resort.

02 · workers

GPU agent nodes

Joined as k3s agents, then configured with the NVIDIA container runtime so GPU workloads can be scheduled directly against the cluster.

03 · networking

Tailscale + Flannel

Tailscale is the host-to-host mesh; Flannel rides on top of it for pod networking. A dedicated recovery step re-establishes flannel.1 when a joined node comes up without it.

04 · management

Rancher

Installed on the control-plane nodes via cert-manager + Helm, with the hostname, replica count and TLS source read from [settings].

05 · operator

cluster-ctl (Rust)

A single static binary. SSH directly to each node — key auth first, password fallback second, sudo password piped over stdin, never on the command line.

06 · boundary

Deployment only

This repo documents and automates deployment. It does not contain the service-workbench application or the paper's experiment code.

Menu

Every step cluster-ctl can run

These are the exact menu entries in the TUI. Click one — the terminal above will replay a realistic log for that step, sourced from what cluster-ctl actually prints.

The real thing

Driven by the exact log cluster-ctl prints

cluster-ctl — ssh session

simulated output, rendered live in a WebGL scene — click a step above to drive it

Local setup

Four steps to a running control plane

  1. 1 Copy cli/cluster.example.toml to cluster.toml and fill in node names, Tailscale addresses/hostnames, and SSH user.
  2. 2 Drop a working kubeconfig at config.yaml if you want "Verify Flannel" to work — it shells out to kubectl.
  3. 3 Build and run cluster-ctl — it tries your SSH keys first, then falls back to a password entered on the startup screen.
  4. 4 Install kubectl locally if you plan to use "Verify Flannel".
shell
# from the repo root
cp cli/cluster.example.toml cluster.toml
$EDITOR cluster.toml

cd cli
cargo run --release

# or point at a config elsewhere
cargo run --release -- path/to/cluster.toml
CLUSTER_CTL_CONFIG=./staging.toml cargo run --release