Add a kubeconfig command

[sagikazarmark]

labctl has no built-in way to obtain a usable kubeconfig from a running Kubernetes playground. Users who want to run kubectl locally must manually SSH in to extract the config, separately expose or forward the API server port, and then rewrite the server address to match. A dedicated labctl kubeconfig command should automate this: extract the config from the playground machine, expose the API server endpoint, and output a kubeconfig with the server address pointed at the locally-reachable endpoint.

Motivation

labctl already bridges the local/remote gap for shells (ssh), editors (ide), and network access (port-forward, expose port). Kubernetes playgrounds are a core use case, yet kubectl access — the most common interaction — still requires manual plumbing across multiple commands. Closing this gap makes the Kubernetes learning and experimentation workflow seamless from the terminal.

Proposed Approach

• Establish a convention for locating kubeconfig inside the playground VM. Two candidates (try in order):
  1. Copy the portable kubeconfig from the default machine's kubectl context (e.g., /etc/kubernetes/admin.conf or ~/.kube/config).
  2. Execute a well-known script (e.g., /usr/local/bin/kubeconfig.sh) if present, to support clusters that generate configs dynamically.
• Make the API server reachable locally and rewrite the server: field in the retrieved config to match.
• Support --machine <name> flag for multi-machine playgrounds where the control plane is not on the default machine.

Additional Context

• Open design question: should the command use port-forward or expose port to make the API server reachable? Trade-offs around persistence, auth, and HTTPS handling differ between the two.
• Open question: how to discover the API server port reliably when different Kubernetes distributions (kubeadm, k3s, kind) use different defaults.
• The existing port-forward, expose port, and ssh commands already solve the underlying primitives — this command orchestrates config extraction and endpoint exposure on top of them.

[iximiuz]

There might be an easier way around it, too:

labctl kubectl <PLAY_ID> <command>
labctl k <PLAY_ID> <command>

And under the hood, just do labctl ssh <PLAY_ID> kubectl <command> (with the --machine and --user flags support, of course).

Alternatively, we can have a command similar to labctl ssh-proxy. Something like labct kube-proxy, which forwards the Kubernetes API port to the local host (and possibly prints the kubeconfig on the screen and/or writes it to a local file). For the implementation, I'd again rely on (ab)using labctl ssh <PLAY_ID> kubectl under the hood as it's the easiest convention to support. I.e., the only thing we'd need from the playground is a working kubectl command on its default machine (and user). And all current official K8s playgrounds already follow this convention.

[sagikazarmark]

I think one of the use cases for this command is deploying something from your own computer.

That's a bit harder with this approach, you would have to copy files first and then use the command: I could just ssh into and do the same.

the only thing we'd need from the playground is a working kubectl command on its default machine (and user). And all current official K8s playgrounds already follow this convention.

If that's convention, we can very easily do a local setup as well.

[iximiuz]

I think one of the use cases for this command is deploying something from your own computer.

Definitely, and labctl k <PLAY_ID> apply -f ./local/path/my.yaml should work just fine. Or a more "advanced" but potentially faster if you need to run many kubectl commands:

# From terminal 1
labctl kube-proxy <PLAY_ID> --kubeconfig-out ~/.kube/play_<PLAY_ID>

# From terminal 2
KUBECONFIG=~/.kube/play_<PLAY_ID> kubectl  apply -f ...