Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

To create a virtual Kubernetes cluster for a team, install the vCluster CLI, connect it to a host cluster, and run vcluster create my-vcluster --namespace team-x. This gives the team its own Kubernetes API and namespace view, but in shared-node mode its workloads still run on the host’s worker nodes and share the host kernel. Use this pattern for trusted internal development, test, and CI/CD tenants—not as a security boundary for untrusted workloads.

What a vCluster separates—and what it does not

A vCluster provides a separate Kubernetes control plane and API experience for a tenant. In shared-node mode, the virtual cluster is hosted in a namespace on an existing Kubernetes cluster. Its syncer translates selected resources—including Pods, ConfigMaps, Secrets, Services, Ingress, and Gateway API objects—into the underlying environment. See the vCluster v0.37 documentation for current architecture and operational details.

This separates Kubernetes API and namespace views, not the worker infrastructure: tenant workloads still share the host cluster’s nodes and kernel. The official shared-node quick start describes this as a supported model for trusted tenants. Treat that as an internal tenancy pattern, not a substitute for stronger isolation when tenants are untrusted or can run arbitrary workloads.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

NetworkPolicy is not automatic protection. Policy resources must be synced to the host, and the host cluster’s CNI must enforce them. Likewise, network-related resources can require configuration because the syncer maps tenant objects into the host environment.

Prerequisites for creating a team cluster

  • An accessible Kubernetes host cluster and kubectl configured with a context that can create the resources needed for the vCluster.
  • At least 2 vCPU and 2 GB RAM of available capacity, the minimum stated in the quick start. This is a tutorial prerequisite, not a production sizing recommendation; actual capacity depends on the control plane and tenant workloads.
  • The vCluster CLI, installed using the current official instructions for your operating system in the quick start. Avoid treating a URL or command that installs “latest” as a fixed version pin; select and manage CLI versions according to your platform’s release policy.

Create the vCluster in its own namespace

  1. Check that kubectl points to the intended host cluster: kubectl config current-context. If it does not, select the correct context using kubectl config use-context CONTEXT_NAME.
  2. Create the tenant cluster in a namespace reserved for the team: vcluster create my-vcluster --namespace team-x. The documented quick start’s version defaults to Kubernetes v1.36.0; defaults may change. If you need a particular Kubernetes version, check the live documentation and configure controlPlane.distro.k8s.image.tag rather than relying on an assumed default.
  3. Wait for the CLI to report that the cluster is ready. The CLI switches your kubeconfig context to the new vCluster, so check it with kubectl config current-context before running commands intended for the tenant.

Verify the tenant API and deploy a test workload

  1. Inspect the tenant’s namespace view: kubectl get namespaces. It should show the virtual cluster’s namespaces, not simply expose the host cluster’s namespace inventory.
  2. Deploy a small test workload in the tenant context, for example: kubectl create deployment hello --image=nginx. Check its status with kubectl get pods. This confirms basic API access and workload synchronization; it does not test or prove a security boundary.
  3. Disconnect from the virtual cluster using vcluster disconnect, then inspect the host namespace: kubectl --context HOST_CONTEXT get pods -n team-x. Replace HOST_CONTEXT with the context name you recorded for the host cluster. The workload should appear in the host namespace with a rewritten name, illustrating how the syncer represents tenant resources in the underlying cluster.

When to use shared nodes or consider private nodes

Choice Isolation and trust Infrastructure and networking
Shared nodes Separate control plane and API view; tenant workloads share host workers and kernel. Best suited to trusted internal teams. Reuses the host node pool with comparatively low infrastructure overhead. Relies on sync behavior and the host cluster’s networking and storage infrastructure.
Private nodes Dedicated infrastructure for a tenant; intended for stronger separation, including external, regulated, or GPU workloads. Requires dedicated compute and brings more infrastructure overhead. Allows tenant-specific infrastructure choices such as CNI and CSI.

Dedicated node placement on a shared-node cluster can reserve or constrain workload capacity, but it does not turn that architecture into private-node isolation. Choose private nodes when the tenant’s trust level or requirements call for dedicated infrastructure.

Optional: check NetworkPolicy behavior

A policy object is useful only if the host-side policy is present and the CNI enforces NetworkPolicy. For a meaningful check, enable NetworkPolicy syncing to the host in the vCluster configuration, apply a default-deny policy in the tenant, and test connectivity from a client pod. Confirm enforcement with your host CNI’s documentation or operational checks; a successful policy submission alone does not establish that traffic is blocked.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Choosing a tenancy model for your platform

Keep shared-node vClusters for trusted development, test, and CI/CD teams when API separation and resource reuse meet the requirement. Evaluate private nodes for external, regulated, resale, or otherwise untrusted tenants. Platform tooling can organize tenant projects and access, but it cannot remove the need to choose an appropriate worker isolation model.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.