Constituent parts of the Kubernetes cluster and snapshots of their VMs

Traffic balancer

After initial configuration, it is a stateless host. To make a backup copy, you can take a snapshot of its VM 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 VM 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 VM snapshot is created, depending on the type of hypervisor.
• Restoring from a snapshot breaks current connections.
• From the moment when the VM 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. You can create snapshots of controller VMs 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 VM snapshot while the cluster is running will lead to undefined behavior.
• A controller VM snapshot may only be used to restore the VM 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 Core services. Creating VM 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 VM, 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 VM 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 VM. 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