Skip to main content
Version: main 🚧

Deploy in High Availability

By default, vCluster runs one instance of each of its components. This deployment method is recommended for any uses cases that are very ephemeral (e.g. dev environments, CI/CD, etc.), but for most production use cases, you will want to run vCluster with more redundancy. We recommend deploying vCluster in High Availability (HA) mode to run multiple copies of the vCluster components so that the virtual cluster is more resistant to partial failures.

Configure your vcluster.yaml​

In order to enable the HA mode, you'll need to change the backing store from the embedded database (SQLite) to any of our other backing store options. also need to request how many replicas to deploy.

info

High Availability mode is not compatible with the embedded SQLite as the backing store, which is the default backing store. You must explicitly set an alternative backing store.

Example vcluster.yaml that deploys etcd as the backing store:

controlPlane:
# Deploy etcd instead of using the embedded SQLite
backingStore:
etcd:
deploy:
enabled: true
statefulSet:
highAvailability:
replicas: 3
# Deploy vCluster with 3 replicas
statefulSet:
highAvailability:
replicas: 3

Deploy your vCluster with HA​

Using that vcluster.yaml, we can create a new virtual cluster in HA mode.

vcluster create ha-tutorial --connect=false -f vcluster.yaml

This will create a virtual cluster called ha-tutorial. By default, the vcluster create command connects to the vCluster after creation, and switches your kube context to point to the new virtual cluster. By adding in --connect=false as part of the command, the kube context will not switch and your kube context will remain pointed at the host cluster that you deployed the vCluster on.

Check the pods of the vCluster on the host cluster​

Since the kube context is still set as the host cluster, we can get the pods in the namespace of the new virtual cluster. The namespace is called vcluster-ha-tutorial in the host cluster, and contains the components of the vCluster.

kubectl get pods -n vcluster-ha-tutorial
NAME                                      READY   STATUS    RESTARTS   AGE
ha-tutorial-7c5c5844c5-27j2v 0/1 Running 0 20s
ha-tutorial-7c5c5844c5-gb2sm 0/1 Running 0 20s
ha-tutorial-7c5c5844c5-pwn7k 0/1 Running 0 20s
ha-tutorial-etcd-0 0/1 Running 0 20s
ha-tutorial-etcd-1 0/1 Running 0 20s
ha-tutorial-etcd-2 0/1 Running 0 20s

There are three replicas of each component (control plane and etcd) of the vCluster running. If one API server pod goes down, the vCluster would continue working.

In order to see which nodes in the host cluster that these pods were scheduled on, add the -o wide flag to the kubectl get pods command:

kubectl get pods -n vcluster-ha-tutorial -o wide

The hostnames of the nodes will be listed in the NODES column.