Day 1: Introduction to vind: Why I Replaced KinD with vCluster in Docker [vind]

If you’ve been working with Kubernetes for a while, you’ve probably used KinD (Kubernetes in Docker). I’ve used it extensively for my local development, CI pipelines, demos, you name it. And for what it does, it works. But I’ve always felt like there was something missing.

That’s why we built vind to solve some of the shortcomings of KinD.

What is vind?

vind stands for vCluster in Docker. It’s a new way to run local Kubernetes clusters using the Docker driver. Instead of spinning up KinD clusters, you use the same vCluster CLI you might already know but pointed at Docker as the backend.

The result? A local Kubernetes cluster that runs entirely in Docker containers, just like KinD, but with a bunch of features that KinD simply does not have.

Why I Switched

Overall KinD is great for basic use cases. But the moment you need anything beyond a simple single-node cluster, you start hitting walls:

• No LoadBalancer support: You need MetalLB or some workaround. With vind, LoadBalancer services work out of the box.

• No sleep/wake: Delete and recreate every time. With vind, you can pause a cluster and resume it later.

• No UI: KinD is purely CLI. vind has the vCluster Platform UI(Free) for visual management.

• No external nodes: KinD is local-only. vind lets you join real cloud VMs (GCP, AWS) as worker nodes via VPN backed by tailscale.

• Manual image loading: KinD load docker-image every time, vind has a registry proxy that shares your Docker daemon’s image cache automatically.

The Architecture

Here’s what’s happening under the hood when you create a vind cluster:

Your machine runs Docker. Inside Docker, vind creates:

• A control plane container with the Kubernetes API server, etcd, scheduler, and Flannel CNI (you can customise this too and install cilium)

• Optional worker node containers, each one is a full node with kubelet and kube-proxy

• A Docker network for inter-node communication

• An HAProxy load balancer for LoadBalancer service support

• A registry proxy that connects to your host Docker’s containerd storage

The beauty of this is that each component runs as a regular Docker container. You can inspect them, view logs, and manage them with standard Docker commands.

Getting Started (Quick Preview)

Here’s how fast you can get a cluster running:

# Install or upgrade the vCluster CLI

brew install loft-sh/tap/vcluster

# or

vcluster upgrade --version v0.32.1

# Set Docker as the driver

vcluster use driver docker

# Create your first cluster

vcluster create my-cluster

That’s it. Three commands and you have a running Kubernetes cluster:

$ vcluster create my-cluster

14:58:13 info Using vCluster driver 'docker' to create your virtual clusters, which means the CLI is managing Docker-based virtual clusters locally
14:58:13 info If you prefer to use helm or the vCluster platform API instead, use '--driver helm' or '--driver platform', or run 'vcluster use driver helm' or 'vcluster use driver platform' to change the default
14:58:13 info Ensuring environment for vCluster my-cluster...
14:58:14 done Created network vcluster.my-cluster
14:58:19 warn Load balancer type services are not supported inside the vCluster because this command was executed with insufficient privileges. To enable load balancer type services, run this command with sudo
14:58:20 info Will connect vCluster my-cluster to platform...
14:58:21 info Starting vCluster standalone my-cluster
14:58:23 done Successfully created virtual cluster my-cluster
14:58:23 info Finding docker container vcluster.cp.my-cluster...
14:58:23 info Waiting for vCluster kubeconfig to be available...
14:58:25 info Waiting for vCluster to become ready...
14:58:37 done vCluster is ready
14:58:37 done Switched active kube context to vcluster-docker_my-cluster
- Use `vcluster disconnect` to return to your previous kube context
- Use `kubectl get namespaces` to access the vcluster

vind vs KinD At a Glance

What’s Coming This Week

Over the next 6 days, I’ll walk you through everything vind can do with real commands, real outputs, and real use cases:

• Day 2: Getting Started: deploying your first app with LoadBalancer

• Day 3: Multi-Node Clusters: realistic multi-node setups with pod distribution

• Day 4: External Nodes: joining a GCP Compute instance to your local cluster

• Day 5: Actions with vind: using the setup-vind GitHub Action

• Day 6: Advanced Features: sleep/wake, registry proxy, and custom networking

• Day 7: The vCluster Platform UI: managing vind clusters visually

If you’re tired of KinD’s limitations and want a local Kubernetes experience that actually feels production-like, follow along. I think you’ll be surprised at what vind can do.

vind is open source: github.com/loft-sh/vind , so do star the repo if you like vind