Kubernetes container

[bhack]

Support for containers running in kubernetes (pod, deployment etc..)

[Chuxel]

@bhack Where are you running Kubernetes? If it's local, you should be able to attach to it after you spin it up. F1 > Remote-Containers: Attach to Running Container...

Would that work for you?

[bhack]

Often it is remote specially when I need special (hardware/data) resources.
I need always to use kubectl cp when I edit a file in vscode.

[bhack]

Have you collaboration with https://github.com/Azure/vscode-kubernetes-tools Azure team?

[Chuxel]

@bhack Definatley something we've been thinking about which is partly why I asked about the scenario. We actually have a dev container defintion that allows you to use a Docker sandbox container with all the needed tools (kubctl, helm docker, etc) so you can containerize your build toolchain and still use Kubernetes extension and deploy to a Kubernetes cluster from there: https://github.com/Microsoft/vscode-dev-containers/tree/master/containers/kubernetes-helm

F1 > Create Container Configuration File... > Kubernetes & Helm

[bhack]

F1 > Remote-Containers: Attach to Running Container... for remote K8s could be a good initial feature here.

[bhack]

Just to clarify I meant, as first useful feature, the same use case at (but for K8s):
https://code.visualstudio.com/docs/remote/containers#_attaching-to-running-containers

While using VS Code to spin up a new container can be useful in many situations, it may not match your workflow and you may prefer to "attach" VS Code to an already running container.

Cause my K8S remote workflow "may not match" VS Code spin up.

[Chuxel]

@bhack Yep - totally makes sense. Use kubectl to get to the pod instead of the Docker CLI. K8s configs are more complicated to manage in general so starting with an attach flow makes sense.

[bhack]

I've a question about the server side/extensions. Cause the container/pod nature it is ephemeral how do you handle server side extensions over containers? Do you need to re-configure the remote container extensions every time?

[bhack]

Also I don't understand what could be the case between remote vs container for remote-container K8s case:


We need to suppose that the running code is in the container (i.e. from init container, persitent volume, remote mount, etc) but remote/local edits need to be in sync with the local/remote files.
So there in not a volume mount of a local path like in your current "local" container case.
We need to have an auto-sync over the "source code block" in the diagram.

[bhack]

About source code block sync check ernoaapa/kubectl-warp#10.
As mentioned there I don't know if a sidecar injector could be a good strategy.

[chrmarti]

Extensions running in the container need to be installed in each container. That happens automatically for the extensions listed in the devcontainer.json.

The files don't have to be local for VS Code to work on them. You could just check out the files in the container.

[bhack]

No the problem is that you work on remote files but generally you git commit changes locally. So we need a sync.

[chrmarti]

If you commit / push through the Git viewlet in VS Code, you do it on the remote side currently.