The third, and final release in our Future of Kubernetes Tenancy launch series has arrived, but first let’s recap the previous two installments. Private Nodes and Auto Nodes established a new tenancy model that entirely shifts how vCluster can be deployed and managed:

• Private Nodes allows users to join external Kubernetes nodes directly into a virtual cluster, ensuring workloads run in a fully isolated environment with separate networking, storage, and compute. This makes the virtual cluster behave like a true single-tenant cluster, removing the need to sync objects between host and virtual clusters.

• Auto Nodes, built on the open-source project Karpenter, brings on-demand node provisioning to any Kubernetes environment - whether that is in a public cloud, on-premise, bare metal, or multi-cloud. It includes support for Terraform/OpenTofu, KubeVirt, and NVIDIA BCM as Node Providers, making it incredibly flexible. Auto Nodes will rightsize your cluster for you, easing the maintenance burden and lowering costs.

Today’s release yet again expands how vCluster can operate. Up until now, vCluster has always needed a host cluster which it is deployed into. Even with private nodes, the control-plane pod lives inside a shared cluster. For many people and organizations this left a “Cluster One” problem: where and how would they host this original cluster? vCluster Standalone provides the solution to this problem.

Standalone runs directly on a bare metal or VM node, spinning up the control plane and its components as a process running directly on the host using binaries rather than launching the control plane as a pod on an existing cluster. This gives you the freedom and flexibility to install in any environment, without additional vendors.

After an initial control plane node is up, you can easily make the control plane highly available by joining additional control plane nodes to the cluster and enabling embedded etcd across them.

Joining control plane nodes works the same way as joining worker nodes using the private nodes approach for joining nodes. Besides manually adding worker nodes to a Standalone cluster, you can also use Auto Nodes to automatically provision worker nodes on demand.

Let’s look at an example. SSH into the machine you want to use for the first control plane node and create a vcluster.yaml file as shown below. In this case we’ll also enable joinNode to use this host as a worker node in the cluster in addition to being a control plane node:

# vcluster.yaml
controlPlane:
  # Enable standalone
  standalone:
    enabled: true
      # Optional: Control Plane node will also be considered a worker node 
      joinNode:
        enabled: true
# Required for adding additional worker nodes
privateNodes: 
  enabled: true

Now, let’s run this command to bootstrap our vCluster on this node:

sudo su -
export VCLUSTER_VERSION="v0.29.0"
curl -sfL https://github.com/loft-sh/vcluster/releases/download/${VCLUSTER_VERSION}/install-standalone.sh | sh -s -- --vcluster-name standalone --config ${PWD}/vcluster.yaml

A kubeconfig will be automatically configured, so we can directly use our new cluster and check out its nodes:

$ kubectl get nodes

NAME               STATUS   ROLES                  AGE   VERSION
ip-192-168-1-101   Ready    control-plane,master   10m   v1.32.1

That’s it, you now have a new Kubernetes cluster! From here you can join additional worker nodes, or additional control-plane nodes to make the cluster highly available.

To add additional nodes to this cluster, SSH into them and run the node join command. You can generate a node join command by ensuring your current kube-context is using your newly created cluster and then running this command:

# Generate Join Command For Control Plane Nodes (for HA)
vcluster token create --control-plane

# Generate Join Command For Worker Nodes
vcluster token create

To manage or update the vCluster simply adjust /var/lib/vcluster/config.yaml and then restart the vCluster service using this command:

systemctl restart vcluster.service

vCluster Standalone streamlines your infrastructure by removing the need for external providers or distros. It delivers a Kubernetes cluster that is as close to upstream vanilla Kubernetes as possible while adding additional convenience features such as etcd self-healing and others available to any vCluster. Launching a vCluster Standalone cluster allows you to bootstrap the initial cluster required to host your virtual clusters and vCluster Platform but it can also be used to run end-user workloads directly.

See the documentation for further details, full configuration options and specs.

Notable Improvements

Setting new fields via patches

Until now, virtual clusters only supported patching existing fields. With v0.29 we have added functionality to set new fields as well, including conditionally based on an expression. This broadens how pods can interact with existing mechanisms inside the host cluster. For more information see the docs about adding new keys.

Other Announcements & Changes

• Etcd has been upgraded to v3.6. The upstream etcd docs state that before upgrading to v3.6, you must already be on v3.5.20 or higher, otherwise failures may occur. This version of etcd was introduced in vCluster v0.24.2. Please ensure that you have upgraded to at least that version, before upgrading to v0.29.

• The External Secret Operator integration configuration was previously reformatted, and the original config options have now been removed. You must convert to the new format before upgrading to v0.29. For more information please see the docs page.

For a list of additional fixes and smaller changes, please refer to the release notes.

This release completes our Future of Kubernetes Tenancy launch series. We hope you’ve enjoyed following us this summer, and experimenting with all the new features we’ve launched. As we head towards fall, we hope to hear more from you, and look forward to speaking directly at the upcoming KubeCon + CloudNativeCon conferences in Atlanta and Amsterdam!