VS Code Setup for Cloud-Native Development

The extensions and Dev Containers setup that make VS Code feel purpose-built for Docker, Kubernetes, and polyglot projects.

A default VS Code install is a good editor. A few extensions and one config file turn it into an environment that understands Docker images, Kubernetes manifests, and remote/containerized dev — without leaving the editor.

Core extensions

Install these from the Extensions panel (Cmd+Shift+X / Ctrl+Shift+X), or from the command line:

code --install-extension ms-azuretools.vscode-docker
code --install-extension ms-kubernetes-tools.vscode-kubernetes-tools
code --install-extension ms-python.python
code --install-extension dbaeumer.vscode-eslint
code --install-extension esbenp.prettier-vscode
code --install-extension eamodio.gitlens
code --install-extension redhat.vscode-yaml

What each one earns its place for:

Docker — lints your Dockerfile, lets you browse images/containers/ volumes from the sidebar, right-click a Dockerfile to build it.
Kubernetes — autocomplete and inline validation against the real Kubernetes schema for any YAML that looks like a manifest, plus a cluster browser.
Python — IntelliSense, debugging, and automatic virtual environment detection (it'll notice a .venv and offer to use it as the interpreter).
ESLint / Prettier — lint errors inline, format-on-save.
GitLens — inline blame annotations, easy history browsing per line.
YAML (Red Hat) — schema validation for YAML generally; pairs with the Kubernetes extension rather than replacing it.

tip

Skip installing more than one extension for the same job (two Python extensions, two Docker extensions). Overlapping extensions commonly fight over the same status bar space or IntelliSense provider — one clear winner per language/tool is more stable than several partially-working ones.

Format and lint on save

Add this to your workspace .vscode/settings.json (commit it — it's project config, not personal preference, so the whole team gets the same behavior):

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

Dev Containers: your editor, inside the project's actual environment

The Dev Containers extension reopens your project inside a Docker container — so "works on my machine" becomes "works in the container everyone uses," including whichever Node/Python version and system libraries the project needs.

code --install-extension ms-vscode-remote.remote-containers

Add a .devcontainer/devcontainer.json:

{
  "name": "project-dev",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Command Palette → Dev Containers: Reopen in Container. VS Code builds (or pulls) the image, mounts your project into it, and every terminal and extension inside that window now runs against the containerized environment — not your host machine's Node install.

note

This needs Docker running (see the Docker setup guide) — Dev Containers uses it under the hood to build and run the container your editor connects into.

Remote-SSH, for a machine you don't develop on locally

Different problem, same shape: Remote - SSH opens a folder on a remote server as if it were local — useful for a beefy dev box or a cloud VM instead of a container.

code --install-extension ms-vscode-remote.remote-ssh

Command Palette → Remote-SSH: Connect to Host, enter user@host, and VS Code installs its server component remotely and reopens against it.

Common gotchas

warning

Dev Containers builds every time, slowly. The first build is always slow (pulling/building the image); subsequent reopens should reuse the built image. If it's rebuilding every time, check you're not invalidating the Docker layer cache with something that changes on every commit early in the Dockerfile.

warning

Python extension picks the wrong interpreter. Command Palette → Python: Select Interpreter and pick your .venv explicitly — the auto-detection sometimes prefers a system Python if the virtual environment wasn't created before the folder was first opened.

With this in place once per machine (and .vscode/settings.json + .devcontainer/ committed per project), opening any project in this knowledge base's stack — Node, Python, Docker, Kubernetes manifests — gets the right tooling automatically instead of piecemeal, per project.