VS Code Dev Containers + Docker + Kubernetes Integration

Look, if you've been developing anything that touches Kubernetes, you know the pain: your local environment is completely different from staging, which is different from prod, and nobody can reproduce the fucking bugs because "it works on my machine."

I spent three years dealing with this shit before dev containers saved my sanity.

The Real Problem

You're building a microservice that needs to talk to Redis, PostgreSQL, and some message queue. Locally, you have different versions, different configs, different network setups. Your teammate runs macOS while you're on Linux. The junior dev just joined and spent two weeks trying to get the environment working.

And then - because of course - someone deploys to Kubernetes and suddenly everything breaks. Container runtime is different, networking works differently, secrets are mounted in different paths. Classic.

How VS Code Dev Containers + K8s Actually Works

The Dev Containers extension lets you code inside a Docker container that matches your production environment. Not "similar to" - actually matches. The official container specification defines how this works, and Microsoft's documentation walks through the setup process.

Docker-in-Docker vs Docker-outside-of-Docker: This is where most people fuck up. Docker-in-Docker is "pure" but slow as molasses. Docker-outside-of-Docker mounts your host Docker socket, which is faster but can break on SELinux systems (learned that one the hard way). The Docker security documentation explains the implications.

Kubernetes Integration: The Kubernetes extension is actually decent. You can deploy straight to your cluster, check logs, port-forward services - all without leaving VS Code. Beats switching between terminal tabs constantly. The kubectl reference and Kubernetes concepts guide provide essential background.

Real-World Setup

Here's what actually works in production:

{
  "name": "Microservice Dev Environment",
  "dockerFile": "Dockerfile.dev",
  "features": {
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
    "ghcr.io/devcontainers/features/kubectl-helm-minikube:1": {}
  },
  "remoteEnv": {
    "KUBECONFIG": "/workspace/.kube/config"
  },
  "mounts": [
    "source=${localEnv:HOME}/.kube,target=/home/vscode/.kube,type=bind"
  ],
  "postCreateCommand": "kubectl config use-context development"
}

Warning: That kubeconfig mount breaks if your username has spaces or non-ASCII characters. I think it was Docker 4.2 where this got really bad? Maybe 4.3? Either way, Docker's path handling is garbage for edge cases.

Why This Actually Matters

Once you set this up right:

• New developers are productive in like half an hour instead of spending days installing shit
• Your dev environment failures actually predict production failures
• No more "works locally but crashes in staging" surprises
• Everyone debugs the same way, with the same tools, same versions

The setup takes about an hour if you know what you're doing, maybe 4 hours if you hit the gotchas. Or like 8 hours if you're on Windows and everything decides to break. But it saves weeks of debugging environment-specific bullshit later.

Currently at something like 2+ million downloads because developers are tired of environment hell. The devcontainers spec is actually becoming a standard, which is shocking for something Microsoft touched. GitHub Codespaces uses the same spec, and I think AWS Cloud9 does too.

The implementation details that follow will save you from the usual Docker-Kubernetes integration nightmare. Because nothing's worse than spending a week debugging an environment setup when you should be writing actual code.

Time for the real shit - how to actually set this up without losing your mind. I've done this setup probably 50 times across different teams, and here's what I've learned from all the failures.

Prerequisites: More Than the Docs Tell You

The official requirements are bullshit. Here's what you actually need:

Hardware Reality Check:

• 8GB RAM minimum (not 2GB - that's a joke for K8s workloads)
• Docker Desktop will randomly eat 4GB just sitting there doing nothing
• Minikube needs another 2-4GB depending on what you're running, sometimes more if you're unlucky
• SSD required unless you enjoy 5-minute container startups (I'm not joking, I've seen it)

Software That Actually Works:

• Docker Desktop 4.0+ (older versions break randomly)
• VS Code with the Dev Containers extension
• Working kubectl config (test it first: kubectl get nodes)
• Git for version control integration
• Node.js if you're working with JavaScript/TypeScript projects

The Setup That Won't Destroy Your Sanity

Option 1: Docker-outside-of-Docker (Recommended for Speed)

This mounts your host Docker socket. Fast but can break on some systems:

{
  "name": "K8s Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
    "ghcr.io/devcontainers/features/kubectl-helm-minikube:1": {}
  },
  "mounts": [
    "source=${localEnv:HOME}/.kube,target=/home/vscode/.kube,type=bind"
  ],
  "remoteEnv": {
    "KUBECONFIG": "/home/vscode/.kube/config"
  },
  "postCreateCommand": "kubectl config current-context"
}

Gotchas with this approach:

• Breaks on SELinux systems (learned this on a Red Hat box at 2am when nothing worked)
• Docker builds use host cache (good) but paths get weird (bad) - especially when your project is in /Users/some long folder name/
• If your username has spaces, the mount fails silently - thanks Microsoft for encouraging spaces in usernames
• Security implications of mounting Docker socket (basically giving the container root access to your entire system)

Option 2: Docker-in-Docker (Slower but More Reliable)

Runs a separate Docker daemon inside the container:

{
  "name": "K8s Dev (Isolated)",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/devcontainers/features/kubectl-helm-minikube:1": {}
  },
  "privileged": true,
  "mounts": [
    "source=${localEnv:HOME}/.kube,target=/home/vscode/.kube,type=bind"
  ],
  "postCreateCommand": "minikube start --driver=docker --memory=4096"
}

Gotchas with this approach:

• Minikube inside Docker inside Docker is slower than a Windows 95 boot sequence
• Uses 2x memory because nested virtualization - killed my 8GB MacBook Air more than once
• Sometimes the Docker daemon inside fails to start and the error message tells you nothing useful (restart the container and pray)
• Privileged mode security concerns - your security team will have words with you

Real Kubernetes Integration Patterns

Local Minikube (Best for Solo Development):

## Start Minikube with enough resources
minikube start --memory=4096 --cpus=2 --driver=docker

## Test it works
kubectl get nodes

Add this to your devcontainer.json:

{
  "postCreateCommand": "kubectl config use-context minikube"
}

See the Minikube documentation and driver configuration guide for detailed setup instructions.

Docker Desktop Kubernetes (Easiest Setup):

Enable Kubernetes in Docker Desktop settings. That's it. No joke, it just works. Check the Docker Desktop documentation for troubleshooting.

Remote Clusters (For Teams):

## Get your kubeconfig
kubectl config view --raw > ~/.kube/config

## Test you can reach it
kubectl cluster-info

For production clusters, see AWS EKS setup, Google GKE configuration, or Azure AKS deployment.

Common Fuckups and How to Fix Them

"Cannot connect to the Docker daemon":

## Check if Docker is actually running
docker version

## If using docker-outside-of-docker, restart the container
## The socket mount probably broke

"The connection to the server localhost:8080 was refused":
Your KUBECONFIG is fucked. Here's the debug process:

echo $KUBECONFIG
kubectl config current-context

## Fix it by setting the right context
kubectl config use-context your-actual-context

"minikube start" fails inside container:

## Minikube needs privileged mode and enough resources
## Add to devcontainer.json:
"privileged": true,
"postCreateCommand": "minikube start --driver=docker --memory=4096 --no-vtx-check"

This usually works but sometimes Minikube wakes up and chooses violence for absolutely no reason.

File sync is slow as hell on macOS:

• Use the `:cached` mount option
• Consider osxfs alternatives like docker-sync
• Or just accept it's slower than a DMV line and invest in some SSD therapy
• Check Docker Desktop performance tips

Testing Your Setup

Run these inside your dev container to make sure nothing's broken:

## Docker works
docker run hello-world

## Kubernetes is reachable  
kubectl get nodes

## You can build images
docker build -t test .

## Port forwarding works
kubectl port-forward svc/some-service 8080:80

If any of these fail, your setup is fucked and you need to fix it before continuing.

Pro Tips From Pain

• Always pin your feature versions in devcontainer.json or the next Microsoft update will torpedo your entire setup
• The docker-outside-of-docker pattern fails silently on SELinux systems (discovered this during a 3am deployment on a Red Hat production box - not my finest hour)
• Kubernetes contexts get corrupted like clockwork - I keep three backup copies of working kubeconfig files now
• Docker Desktop licensing costs actual money for teams bigger than 250 people (legal called me at 4:30pm on a Friday about this - thanks Docker)
• Use dev container features instead of custom Dockerfiles when possible - less shit to maintain
• Enable VS Code settings sync or you'll spend your life reconfiguring extensions in every container
• Never, ever let Docker Desktop auto-update on a team machine - pin that version or suffer the consequences

The setup takes 1-2 hours if everything goes right, 4-8 hours if you hit the gotchas. Or maybe a full day if you're really unlucky and everything decides to break at once. Plan accordingly.

Time to make sense of this mess. The data that follows comes from setting this up across dozens of teams, including all the spectacular failures and the rare victories.