Skip to main content
Two layers — most RL users only care about the first.

​
Inside a forked cluster (your GRPO scenario)

This is the k3s that lives inside the VMs you fork (cluster mode). The fork engine is N-node (tree_create_cluster(vm_count) / adopt any live set) — there is no hard-coded 3. The CI fixture that proves the headline numbers is a 3-node control plane with flannel + kube-proxy and a real in-cluster Deployment; several stock k3s add-ons are still disabled there to keep that path lean. Status below mixes “API can do it” with “fixture exercises it.” If your scenario needs CoreDNS + Ingress tomorrow, say so — re-enabling the stock add-ons is the next fidelity bump, not a redesign. Same for a larger CI fixture: wiring 20 nodes is configuration + RAM, not a new fork feature.

​
Host RuntimeClass (pods as k7d VMs)

This is the outer layer: kubectl on the host schedules pods into k7d microVMs via runtimeClassName: k7. Relevant if you also want single-VM sandboxes, not only whole-cluster forks.