DEV Community: vCluster

Multi-Node Local Kubernetes with vind: Pod Scheduling, Node Drains, and Affinity Rules

vCluster — Thu, 26 Mar 2026 08:00:00 +0000

Yesterday we got started with a single-node vind cluster. That’s great for basic development, but if you want to test pod scheduling, node affinity, anti-affinity, topology constraints, or node drains, you need multiple nodes.

With KinD, multi-node configs work but you’re still limited to local Docker containers with no external node support. vind gives you the same multi-node Docker setup, plus the option to add real cloud nodes later (we’ll cover that in Day 4).

Today, let’s create a 4-node cluster and put it through its paces.

The Configuration

Create a multi-node.yaml file:

experimental:
  docker:
    nodes:
      - name: worker-1
      - name: worker-2
      - name: worker-3

That’s it. This tells vind to create 3 additional worker nodes alongside the control plane. Each worker runs as its own Docker container with kubelet, kube-proxy, and Flannel.

Create the Cluster

Command:

vcluster create multi-node -f multi-node.yaml

Output:

12:57:42 info Using vCluster driver 'docker' to create your virtual clusters, which means the CLI is managing Docker-based virtual clusters locally
12:57:42 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
12:57:42 info Ensuring environment for vCluster multi-node...
12:57:43 done Created network vcluster.multi-node
12:57:47 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
12:57:48 info Will connect vCluster multi-node to platform...
12:57:49 info Starting vCluster standalone multi-node
12:57:51 info Adding node worker-1 to vCluster multi-node
12:57:52 info Joining node vcluster.node.multi-node.worker-1 to vCluster multi-node...
12:58:17 info Adding node worker-2 to vCluster multi-node
12:58:17 info Joining node vcluster.node.multi-node.worker-2 to vCluster multi-node...
12:58:24 info Adding node worker-3 to vCluster multi-node
12:58:24 info Joining node vcluster.node.multi-node.worker-3 to vCluster multi-node...
12:58:31 done Successfully created virtual cluster multi-node
12:58:31 info Finding docker container vcluster.cp.multi-node...
12:58:31 info Waiting for vCluster kubeconfig to be available...
12:58:32 info Waiting for vCluster to become ready...
12:58:32 done vCluster is ready
12:58:32 done Switched active kube context to vcluster-docker_multi-node
- Use `vcluster disconnect` to return to your previous kube context
- Use `kubectl get namespaces` to access the vcluster

Each node takes about 10 seconds to join. Let’s verify:

Command:

kubectl get nodes -o wide

Output:

NAME         STATUS   ROLES                  AGE    VERSION
multi-node   Ready    control-plane,master   122m   v1.35.0
worker-1     Ready    <none>                 122m   v1.35.0
worker-2     Ready    <none>                 122m   v1.35.0
worker-3     Ready    <none>                 122m   v1.35.0

Four nodes, one control plane and three workers. Each has its own IP on the Docker network, running Kubernetes v1.35.0. This looks exactly like a real multi-node cluster.

Deploy and Watch Pod Distribution

Let’s deploy 6 replicas and see how Kubernetes distributes them:

kubectl create deployment web --image=nginx:latest --replicas=6
deployment.apps/web created

After a few seconds:

kubectl get pods -o wide

Output:

NAME                  READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
web-ff44d897b-5ffqt   1/1     Running   0          8s    10.244.5.2   worker-3     <none>           <none>
web-ff44d897b-7vm76   1/1     Running   0          8s    10.244.2.3   worker-1     <none>           <none>
web-ff44d897b-hpf9d   1/1     Running   0          8s    10.244.5.3   worker-3     <none>           <none>
web-ff44d897b-l4c7t   1/1     Running   0          8s    10.244.4.2   worker-2     <none>           <none>
web-ff44d897b-p276z   1/1     Running   0          8s    10.244.2.2   worker-1     <none>           <none>
web-ff44d897b-z77gm   1/1     Running   0          8s    10.244.0.4   multi-node   <none>           <none>

Look at the NODE column, pods are distributed across all 4 nodes: - worker-1: 2 pods (10.244.2.x subnet) - worker-2: 1 pod (10.244.3.x subnet) - worker-3: 2 pods (10.244.4.x subnet) - multi-node (control plane): 1 pod (10.244.0.x subnet)

Each node has its own Flannel subnet. The Kubernetes scheduler is doing real scheduling across real (containerized) nodes.

Test Node Drain

This is where multi-node really shines. Let’s drain worker-3 and watch pods get rescheduled:

Command:

kubectl drain worker-3 --ignore-daemonsets --delete-emptydir-data

Output:

Warning: ignoring DaemonSet-managed Pods: kube-flannel/kube-flannel-ds-fpr8n, kube-system/kube-proxy-dsg8b
evicting pod default/web-ff44d897b-hpf9d
evicting pod default/web-ff44d897b-5ffqt
pod/web-ff44d897b-5ffqt evicted
pod/web-ff44d897b-hpf9d evicted
node/worker-3 drained

Both pods on worker-3 were evicted. Where did they go?
Command:

kubectl get pods -o wide

Output:

NAME                   READY   STATUS    RESTARTS   AGE     IP           NODE         NOMINATED NODE   READINESS GATES
NAME                  READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
web-ff44d897b-7vm76   1/1     Running   0          20m   10.244.2.3   worker-1     <none>           <none>
web-ff44d897b-hchpq   1/1     Running   0          19m   10.244.4.3   worker-2     <none>           <none>
web-ff44d897b-l4c7t   1/1     Running   0          20m   10.244.4.2   worker-2     <none>           <none>
web-ff44d897b-p276z   1/1     Running   0          20m   10.244.2.2   worker-1     <none>           <none>
web-ff44d897b-pc4cx   1/1     Running   0          19m   10.244.0.5   multi-node   <none>           <none>
web-ff44d897b-z77gm   1/1     Running   0          20m   10.244.0.4   multi-node   <none>           <none>

The scheduler created new pods on worker-2 and the control plane node. Zero pods on worker-3. This is exactly how it works in production.

Uncordon when you’re done:

Command:

kubectl uncordon worker-3

Output:

node/worker-3 uncordoned

Testing Node Affinity

With multi-node, you can test real node affinity rules:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker-only
spec:
  replicas: 3
  selector:
    matchLabels:
      app: worker-only
  template:
    metadata:
      labels:
        app: worker-only
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: DoesNotExist
      containers:
      - name: nginx
        image: nginx:latest

This ensures pods only run on worker nodes, not the control plane, something you can only test with multiple nodes.

kubectl apply -f affinity.yaml 
deployment.apps/worker-only created

kubectl get po -owide 
worker-only-86dd84d489-6v98m   1/1     Running   0          15s   10.244.5.4   worker-3     <none>           <none>
worker-only-86dd84d489-hmbq4   1/1     Running   0          15s   10.244.4.4   worker-2     <none>           <none>
worker-only-86dd84d489-xdttw   1/1     Running   0          15s   10.244.2.4   worker-1     <none>           <none>

Pod Anti-Affinity

Force pods to spread across different nodes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spread-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: spread-app
  template:
    metadata:
      labels:
        app: spread-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: spread-app
      containers:
      - name: nginx
        image: nginx:latest

With 3 replicas and 3 workers, each worker gets exactly one pod. Try doing that with a single-node cluster.

kubectl apply -f antiaffinity.yaml 
deployment.apps/spread-app created

kubectl get po  -owide | grep spread
spread-app-596d884c4d-hp585    1/1     Running   0          10s   10.244.4.5   worker-2     <none>           <none>
spread-app-596d884c4d-j4hcm    1/1     Running   0          10s   10.244.5.5   worker-3     <none>           <none>
spread-app-596d884c4d-lj7c5    1/1     Running   0          10s   10.244.2.5   worker-1     <none>           <none>

Environment Variables for Workers

You can pass environment variables to worker containers:

experimental:
  docker:
    nodes:
      - name: worker-1
        env:
          - "CUSTOM_VAR=value1"
      - name: worker-2
        env:
          - "CUSTOM_VAR=value2"
      - name: worker-3

These are Docker container environment variables, useful for differentiating nodes in testing scenarios.

Cleanup

Command:

vcluster delete multi-node

16:18:36 info Using vCluster driver 'docker' to delete your virtual clusters, which means the CLI is managing Docker-based virtual clusters locally
16:18:36 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
16:18:36 info Removing vCluster container vcluster.cp.multi-node...
16:18:39 info Removing vCluster node worker-3...
16:18:40 info Removing vCluster node worker-2...
16:18:42 info Removing vCluster node worker-1...
16:18:44 info Delete virtual cluster instance p-default/multi-node in platform
16:18:44 info Deleted kube context vcluster-docker_multi-node
16:18:44 done Successfully deleted virtual cluster multi-node

Tomorrow: External Nodes

Multi-node with Docker containers is powerful, but what if you need real cloud resources? A GPU instance? A specific CPU architecture? Tomorrow, we’ll add a GCP Compute Engine instance as an external worker node to a vind cluster, all connected via VPN. That’s something KinD simply cannot do.

All commands tested on macOS (Apple Silicon M1) with Docker Desktop and vCluster CLI v0.31.0.

Day 2: Getting Started with vind: Your First Deployment with LoadBalancer

vCluster — Wed, 25 Mar 2026 11:00:00 +0000

Yesterday I introduced vind and why I think it’s a better alternative to KinD. Today, let’s get hands-on. We’ll install vind, create a cluster, deploy an application, and see the built-in LoadBalancer in action.

Prerequisites
You need two things:

Docker installed and running
vCluster CLI v0.31.0 or later # Check Docker

Command:

docker version

Output:

Client:
 Version:           28.5.1
 API version:       1.51
 Go version:        go1.24.8
 Git commit:        e180ab8
 Built:             Wed Oct  8 12:16:17 2025
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.48.0 (207573)
 Engine:
  Version:          28.5.1
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.8
  Git commit:       f8215cc
  Built:            Wed Oct  8 12:18:25 2025
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Install vCluster CLI (macOS)

$ brew install loft-sh/tap/vcluster

Or upgrade if you already have it

Command:

sudo vcluster upgrade --version v0.32.1

Output:

11:49:25 info Downloading version v0.32.1...
11:49:30 done Successfully updated vcluster to version v0.32.1

Verify

Command:

vcluster --version

Output:

vcluster version 0.32.1

Set Docker as the Default Driver

This is the key step that tells vCluster to use Docker instead of an existing Kubernetes cluster:

Command:

vcluster use driver docker

Output:

11:50:00 done Successfully switched driver to docker

You only need to do this once. It persists across sessions.

Create Your First Cluster

Command:

vcluster create blog-demo

Output:

11:58:04 info Using vCluster driver 'docker' to create your virtual clusters, which means the CLI is managing Docker-based virtual clusters locally
11:58:04 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
11:58:04 info Ensuring environment for vCluster blog-demo...
11:58:05 done Created network vcluster.blog-demo
11:58:12 info Will connect vCluster blog-demo to platform...
11:58:13 info Starting vCluster standalone blog-demo
11:58:14 done Successfully created virtual cluster blog-demo
11:58:14 info Finding docker container vcluster.cp.blog-demo...
11:58:14 info Waiting for vCluster kubeconfig to be available...
11:58:17 info Waiting for vCluster to become ready...
11:58:29 done vCluster is ready
11:58:29 done Switched active kube context to vcluster-docker_blog-demo
- Use `vcluster disconnect` to return to your previous kube context
- Use `kubectl get namespaces` to access the vcluster

That took about 20 seconds. Let’s see what we got:

kubectl get nodes -o wide

Output:

NAME        STATUS   ROLES                  AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
blog-demo   Ready    control-plane,master   30s   v1.35.0   172.23.0.2    <none>        Ubuntu 24.04.3 LTS   6.10.14-linuxkit   containerd://2.1.6

A single-node cluster running Kubernetes v1.35.0 with containerd. Let’s check the namespaces:

Command:

kubectl get namespaces

Output:

NAME                 STATUS   AGE
default              Active   108s
kube-flannel         Active   99s
kube-node-lease      Active   108s
kube-public          Active   109s
kube-system          Active   109s
local-path-storage   Active   99s

Everything you’d expect from a real Kubernetes cluster, including Flannel for networking and local-path-storage for persistent volumes.

Deploy an Application

Let’s deploy nginx with 2 replicas and expose it via a LoadBalancer service:

$ kubectl create deployment nginx --image=nginx:latest --replicas=2
deployment.apps/nginx created

Create Service with type:LoadBalancer:

$ kubectl expose deployment nginx --type=LoadBalancer --port=80 --target-port=80
service/nginx exposed

Wait a few seconds for the pods to come up:

Get Pods:

$ kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
nginx-b6485fcbb-6w6gm   1/1     Running   0          29s   10.244.0.4   blog-demo   <none>           <none>
nginx-b6485fcbb-8dvvg   1/1     Running   0          29s   10.244.0.5   blog-demo   <none>           <none>

Get Service:

$ kubectl get svc
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1       <none>           443/TCP        3m31s
nginx        LoadBalancer   10.111.30.236   172.23.255.254   80:31860/TCP   37s

Get Deployments:

$ kubectl get deployments
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   2/2     2            2           69s

Both pods are running. The LoadBalancer service is created, on Linux it gets an external IP automatically. On macOS, you need to run the vCluster create command with sudo to get full LoadBalancer support with HAProxy.

Tip: On macOS, run sudo vCluster create my-cluster to enable LoadBalancer IP assignment via HAProxy. Without sudo, you can still access services via NodePort.

curl 172.23.255.254
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Cluster Management

vind gives you simple commands to manage your cluster lifecycle:

List all clusters

$ vcluster list

Copy

   NAME    | STATUS  | CONNECTED |  AGE
-----------+---------+-----------+--------
  blog-demo | running | True      | 102s

Disconnect from a cluster (keeps it running)

$ vcluster disconnect

Reconnect later

$ vcluster connect blog-demo

Delete when done

$ vcluster delete blog-demo

What’s Under the Hood?

When you create a cluster, vind sets up Docker containers:

$ docker ps --format "table {{.Names}}\t{{.Status}}"

NAMES                                 STATUS
vcluster.lb.blog-demo.nginx.default   Up 3 minutes
vcluster.cp.blog-demo                 Up 6 minutes

vcluster.cp.blog-demo: The control plane container with K8s, etcd, and everything
vcluster.lb.blog-demo.nginx.default: The HAProxy load balancer for LoadBalancer services
You can even peek inside:

View control plane logs

$ docker exec vcluster.cp.blog-demo journalctl -u vcluster --no-pager | tail -5

Mar 06 06:31:14 blog-demo vcluster[188]: 2026-03-06 06:31:14        INFO        commandwriter/commandwriter.go:128        allocated clusterIPs        {"component": "vcluster", "component": "apiserver", "location": "alloc.go:329", "service": "default/nginx", "clusterIPs": "{\"IPv4\":\"10.111.30.236\"}"}
Mar 06 06:31:14 blog-demo vcluster[188]: 2026-03-06 06:31:14        INFO        record/event.go:389        Event occurred        {"component": "vcluster", "object": {"name":"nginx","namespace":"default"}, "fieldPath": "", "kind": "Service", "apiVersion": "v1", "type": "Normal", "reason": "EnsuringLoadBalancer", "message": "Ensuring load balancer"}
Mar 06 06:31:14 blog-demo vcluster[188]: 2026-03-06 06:31:14        INFO        cloudcontrollermanager/loadbalancer_docker.go:247        Image haproxy:3.3-alpine found locally, skipping pull.        {"component": "vcluster"}
Mar 06 06:31:14 blog-demo vcluster[188]: 2026-03-06 06:31:14        INFO        cloudcontrollermanager/loadbalancer_docker.go:198        Started LoadBalancer container vcluster.lb.blog-demo.nginx.default with ip 172.23.255.254 and forward ports enabled        {"component": "vcluster"}
Mar 06 06:31:14 blog-demo vcluster[188]: 2026-03-06 06:31:14        INFO        record/event.go:389        Event occurred        {"component": "vcluster", "object": {"name":"nginx","namespace":"default"}, "fieldPath": "", "kind": "Service", "apiVersion": "v1", "type": "Normal", "reason": "EnsuredLoadBalancer", "message": "Ensured load balancer"}

Check what's running inside the container

$ docker exec vcluster.cp.blog-demo crictl ps

CONTAINER           IMAGE               CREATED             STATE               NAME                     ATTEMPT             POD ID              POD                                       NAMESPACE
0ce64fdd8ec9d       2af158aaca82b       5 minutes ago       Running             nginx                    0                   d6ced28cb4fe5       nginx-b6485fcbb-8dvvg                     default
56f9406394d3e       2af158aaca82b       5 minutes ago       Running             nginx                    0                   e5b6ab67d5930       nginx-b6485fcbb-6w6gm                     default
181ce2847ff1c       b41714cf62496       7 minutes ago       Running             local-path-provisioner   0                   536bc927ec4eb       local-path-provisioner-5b9b9995f4-4d582   local-path-storage
e7ab4ae96019d       e3b7e577b2a83       7 minutes ago       Running             coredns                  0                   c765485409d89       coredns-79cf5f4c56-jh6jv                  kube-system
d1865682d318c       253e2cac1f011       7 minutes ago       Running             kube-flannel             0                   de40359cb6a81       kube-flannel-ds-5frp9                     kube-flannel
c9133c20d5937       de369f46c2ff5       7 minutes ago       Running             kube-proxy               0                   52d2a265d3d3c       kube-proxy-tvd85                          kube-system

Custom Kubernetes Versions

Want a specific Kubernetes version? Easy:

Command:

vcluster create my-cluster \
  --set controlPlane.distro.k8s.version=v1.32.0

Ouput:

NAME         STATUS   ROLES                  AGE   VERSION
my-cluster   Ready    control-plane,master   66s   v1.32.0

No need to find and pull specific node images like with KinD. Just specify the version.

Cleanup

$ vcluster delete blog-demo
info  Removing vCluster container vcluster.cp.blog-demo...
info  Deleted kube context vcluster-docker_blog-demo
done  Successfully deleted virtual cluster blog-demo

Clean and fast.

Tomorrow: Multi-Node Clusters
Today we created a single-node cluster and deployed an app. But what if you need to test pod scheduling across nodes, node affinity, or node drains

Tomorrow, we’ll create a multi-node vind cluster with 3 worker nodes and see pods distributed across them, just like a real cluster.

All commands tested on macOS (Apple Silicon M1) with Docker Desktop and vCluster CLI v0.32.1.

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

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

vCluster — Tue, 24 Mar 2026 08:10:00 +0000

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-cluster14: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

Introducing vMetal: Run Your GPU Data Center Like a Hyperscaler

vCluster — Mon, 23 Mar 2026 11:44:15 +0000

The race to build AI infrastructure is accelerating.

Across the industry, organizations are deploying massive GPU clusters to power the next generation of AI applications. New Neocloud providers are emerging, enterprises are building internal AI factories, and demand for GPU infrastructure continues to surge.

But while buying GPUs has become easier, operating them like a cloud platform is still incredibly difficult.

Selling raw GPU infrastructure is quickly becoming a commodity. To stand out and maximize GPU utilization, providers must deliver something more: a managed platform experience similar to EC2 or EKS, where teams can spin up environments and start running workloads immediately.

Building that experience requires a complex stack of infrastructure systems, from machine provisioning to cluster orchestration to tenant environments and AI platforms. Many of the end-to-end platforms designed to manage infrastructure date back nearly two decades, while newer open source tools tend to solve only individual parts of the problem. As organizations rapidly build new GPU data centers and AI factories, the pace of infrastructure deployment has outgrown the tooling available today. As a result, most organizations end up attempting to stitch together a mix of legacy platforms, open source tools, and custom automation.

At vCluster Labs, we believe AI infrastructure should operate as a unified platform, not a collection of disconnected tools. Today, we’re introducing vMetal, a new bare metal provisioning and lifecycle management layer designed to help Neocloud providers and AI factories turn raw GPU hardware into programmable infrastructure.

The Problem: Operating GPU Infrastructure Is Hard

Buying GPUs is only the first step. Operating them like a cloud platform is another story.

Organizations building GPU infrastructure are expected to deliver an experience similar to hyperscalers, where teams can spin up environments on demand and run workloads immediately. But achieving that experience requires infrastructure capabilities across several layers:

Bare metal provisioning and hardware lifecycle management
Network orchestration across clusters and tenants
Kubernetes cluster operations
Tenant isolation and environment provisioning
AI tooling and GPU scheduling platforms Most organizations attempt to build these capabilities internally or combine multiple tools to approximate them. But building a GPU cloud platform from scratch takes significant engineering effort and time. And time matters. A $10M GPU cluster generating several dollars per GPU hour can lose millions in potential revenue if platform launch is delayed by months.

The challenge is not hardware. It is infrastructure automation. We built vMetal to solve that problem.

Introducing vMetal: Bare Metal Provisioning for AI Infrastructure

vMetal is a new machine management layer within the vCluster Platform that automates the lifecycle of bare metal GPU servers.

It transforms physical infrastructure into programmable capacity that can be provisioned, assigned, upgraded, and repurposed through a centralized control plane. Instead of manually configuring machines or building custom provisioning pipelines, infrastructure operators can manage their entire GPU fleet through a unified system.

With vMetal, organizations can:

Automatically discover machines connected to the network
Provision servers via PXE boot
Manage machine lifecycle events such as upgrades or reconfiguration
Assign machines directly to Kubernetes clusters or infrastructure pools
Prepare machines for multi-tenant environments

The result is a system where bare metal behaves more like cloud infrastructure. Servers become resources that can be allocated, reassigned, and managed through software workflows rather than manual operations.

From Rack to Cluster in Minutes

Bringing new GPU hardware online is traditionally slow and manual. Servers often require installation, configuration, and networking setup before they can even be attached to a cluster.

vMetal automates this entire process. Using automated provisioning and PXE-based bootstrapping, machines can move from rack installation to cluster-ready nodes in minutes.

Infrastructure operators can:

Power on machines
Automatically install operating systems
Apply configuration and networking policies
Attach nodes to Kubernetes clusters

All through the vCluster Platform.

This dramatically reduces the time required to expand GPU capacity and allows infrastructure teams to operate clusters with the speed and flexibility expected from modern cloud environments.

Certified Stacks: Pre-Validated AI Platforms You Can Deploy in One Command

Provisioning infrastructure is only part of the challenge. Platform teams still need to assemble the tooling required for real AI workloads, including GPU scheduling systems, platform services, and AI development frameworks. That is where vCluster Certified Stacks come in.

Certified Stacks provide tested and maintained blueprints for deploying AI-ready platforms, combining:

vCluster tenancy configurations
Kubernetes platform components
GPU scheduling and workload orchestration
AI tooling and development environments

These stacks allow platform teams to deploy complete AI environments quickly while still retaining the flexibility to customize their infrastructure.

The first Certified Stacks support a growing ecosystem of AI infrastructure platforms, including:

NVIDIA Run:ai for enterprise GPU orchestration
SkyPilot for running and scaling AI workloads across infrastructure
Ray for distributed AI applications and model training
Slinky for AI platform orchestration

Each stack is delivered as a maintained Terraform blueprint, enabling teams to go from infrastructure to a working AI platform in a repeatable and reliable way.

The New Infrastructure Stack for AI

With the introduction of vMetal and vCluster Certified Stacks, the vCluster ecosystem now spans the full infrastructure stack required to run AI workloads. Organizations building GPU clouds or enterprise AI platforms can deploy a layered architecture designed specifically for AI infrastructure.

vMetal: Bare metal machine management that provisions and operates GPU servers.
vCluster: Tenant and cluster orchestration that enables multiple teams or customers to safely share Kubernetes infrastructure.
vNode: Secure runtime isolation for AI workloads running inside shared clusters.
vCluster Certified Stacks: Preconfigured AI environments that combine GPU scheduling, platform services, and AI tooling.

Together, these layers create a unified system capable of running AI workloads from physical machines all the way up to production AI environments.

Turn Your GPU Racks Into a Cloud Platform

Running AI at scale requires more than powerful hardware. It requires infrastructure capable of coordinating machines, clusters, tenants, and workloads across an entire platform.

With the introduction of vMetal and Certified Stacks, the vCluster ecosystem now provides a unified stack for AI infrastructure: Bare Metal → Kubernetes → Tenant Environments → AI Platforms

Instead of stitching together dozens of tools, platform teams can now build AI infrastructure using components designed to work together from the start.

If you’re building GPU infrastructure for a Neocloud or AI factory and want to learn more, visit vMetal.