Constituent parts of the Kubernetes cluster and snapshots of their virtual machines

Traffic balancer

After initial configuration, the load balancer is a stateless host. To make a backup copy, you can take a snapshot of its virtual machine at any time after installing the current version of KUMA. Likewise, the virtual machine can be restored from a snapshot at any time, as long as that the KUMA version of the virtual machine snapshot is the same as the current KUMA version. If the versions are different, the traffic balancer configuration file may need to be edited to reflect any changes in the list of served ports.

Limitations:

• Current connections may be broken at the moment when a virtual machine snapshot is created, depending on the type of hypervisor.
• Restoring from a snapshot breaks current connections.
• From the moment when the virtual machine is restored from a snapshot and until new connections are established, the KUMA Core is unavailable.

Cluster controller

Controllers manage the cluster, and the quorum of the controllers must always be maintained during the operation of the cluster.

A controller may be shut down for a short time as long as overall quorum is maintained. Controller virtual machine snapshots can be created one by one. The main limitation is as follows: if the creation of the snapshot causes temporary unavailability of k0s services, depending on the hypervisor, enough time must be allowed between snapshots for the consensus to be restored and for the etcd database of the cluster to be re-synchronized.

Limitations:

• Restoring one or more controllers from a virtual machine snapshot while the cluster is running will lead to undefined behavior.
• A controller virtual machine snapshot may only be used to restore the virtual machine before completely removing the KUMA Core cluster and then reinstalling the KUMA Core from scratch and recovering from a backup copy.

Worker node of the cluster

Worker nodes of the cluster run the KUMA Core and store replicas of the persistent storage volume used by the KUMA Core services. Creating virtual machine snapshots negatively affects the state of the storage volume; from the introduction of errors in the replica with automatic re-creation of the replica to errors in the file system that necessitate completely shutting down the volume and stopping KUMA Core pods. The consequences depend on the type of hypervisor, the operating system of the virtual machine, the state of all replicas and the intensity of disk operations at the time when the snapshot is created.

Limitations:

Restoring a worker node from a virtual machine snapshot while the cluster is running can lead to the cluster becoming inoperable. Even using a snapshot of a temporarily decommissioned working node does not allow the re-introduction of such a node into the cluster after restoring its virtual machine. Snapshots of worker nodes taken just before the installation of the KUMA Core can be useful. Such snapshots may facilitate the preparation of the KUMA Core reinstallation during recovery.

Page top