You might say: “Wasn’t this possible with Kind?”. In theory - yes. In practice that meant DinD and a lot of friction. vCluster takes a smarter path.

A vCluster is a virtual cluster living inside a namespace of a host cluster, yet it behaves like a fully independent environment - with its own API server, control plane and resource state.

How does that work?

1️⃣ A virtual control plane When you create a vCluster, it doesn’t spin up VMs. It deploys a small StatefulSet pod that contains the control plane: API server, controller manager and a lightweight datastore (SQLite by default, etcd supported). Result? You can run dozens of “clusters” on one host with the overhead of just a few pods.

2️⃣ Shared workers via the Syncer vClusters don’t have their own nodes. They rely on the host cluster. When you create a Deployment in the vCluster it’s stored in the virtual control plane. The Syncer then mirrors the needed resources into the host namespace where the real scheduler places them on actual nodes. You get strong isolation and tenant autonomy without duplicating infrastructure.

This could’ve dramatically changed the course of a lot of projects: Kubernetes operators, drivers, plugins - name it.

On top of that vind ships with a built-in UI, supports pause/resume, spins up in ~30–60 seconds, syncs resources both ways, supports multiple Kubernetes flavors and can back its state with etcd or SQL databases (embedded or external). You can even attach multiple host clusters to a single platform for true multi-tenancy.

Supercharge your CI/CD with ephemeral virtual clusters - and set the “captain” adrift.🌊🛥️

2026-02-14 13:34:54 +0400 +0400 - Radagast the Brown