Skip to main content

Configure vCluster.Pro High Availability Mode

By default, vCluster.Pro will run in a cluster as a single replica without high availability.

Licensed Feature

Running vCluster.Pro in high availability mode is an enterprise feature!

Enable High-Availability and run vCluster.Pro with multiple replicas​

To configure vCluster.Pro to be highly available, you only have to scale up the replicas and vCluster.Pro will start with leader election mode. You can do that via helm on an existing vCluster.Pro installation:

# Run vCluster.Pro with 3 replicas
helm upgrade loft vcluster-control-plane --repo https://charts.loft.sh/ \
  --namespace vcluster-pro \
  --reuse-values \
  --set replicaCount=3

Now check that 3 replicas are running:

$ kubectl get po -n vcluster-pro
NAME                     READY   STATUS    RESTARTS   AGE
loft-84bfdb746c-7t922    1/1     Running   0          40s
loft-84bfdb746c-jpwlz    1/1     Running   0          40s
loft-84bfdb746c-9c4jx    1/1     Running   0          40s

How does it work?​

To understand how vCluster.Pro can be made high available and scaled to multiple replicas, we have to take a look at the core components of vCluster.Pro:

  1. Api Server: vCluster.Pro starts an internal kubernetes api server that handles most of the functional requests vCluster.Pro receives. Since vCluster.Pro does not store any data in any volumes and rather saves everything in kubernetes resources, this component can be easily scaled horizontally.

  2. Controller: a significant part of vCluster.Pro is reacting on kubernetes resource changes and changing other kubernetes resources in return. This part is very similar to the kube-controller-manager which executes the core control loops for kubernetes. Running multiple instances of this component would result in conflicting changes and race conditions among the controllers, this is why leader-election is used. Leader election allows running multiple instances where a single leader is elected that executes the actual functionality, while all other instances are waiting. As soon as the leader fails for any reason another replica takes over.

Since for simplicity and performance reasons both components are compiled into the same binary in vCluster.Pro, scaling of vCluster.Pro works a little bit different than with kubernetes components. The difference is that vCluster.Pro uses a combination of leader election and simple horizontal scaling to ensure high-availability. Essentially vCluster.Pro uses leader election to determine which replica is a leader and which a non leader and depending on which starts in a different mode:

  1. Leader Mode: If a vCluster.Pro replica runs as a leader, all functionality is started like normal, so both api server and controllers are running.
  2. Non-Leader Mode: If a vCluster.Pro replica runs as a non leader, all functionality except the controllers are started, so only the api server is running. If the leader fails for any reason and this replica is made the new leader, vCluster.Pro simply starts the controller component within this replica.

If configured, vCluster.Pro determines automatically which replica to run in leader mode and which to run in non-leader mode. With this approach it is possible to run multiple instances of the api server and allow horizontal scaling for that component, while ensuring the controllers are only run once.

Last updated on