Distributed installation in a high availability configuration

You can make KUMA high availability by deploying KUMA Core on a Kubernetes cluster and by using an external TCP traffic balancer.

To create a high availability KUMA installation, use the kuma-ansible-installer-ha-<build number>.tar.gz installer and prepare the k0s.inventory.yml inventory file by specifying the configuration of the cluster. When installing KUMA in a high availability configuration, OOTB resources are always imported. You can also perform an installation with demo services deployment. To do this, specify the deploy_example_services: true setting in the inventory file.

The KUMA Core can be placed in a Kubernetes cluster in the following ways:

• Install KUMA on a Kubernetes cluster from scratch.
• Migrate the Core of an existing KUMA installation to the Kubernetes cluster.

  To migrate KUMA Core to a new Kubernetes cluster:

  1. Prepare the k0s.inventory.yml inventory file.

     The kuma_core, kuma_ collector, kuma_correlator, kuma_storage sections of your k0s.inventory.yml inventory file must contain the same hosts that were used when KUMA was upgraded from version 2.1.3 to version 3.0.3 or when a new installation was performed. In the inventory file, set the deploy_to_k8s, need_transfer and airgap parameters to true. The deploy_example_services parameter must be set to false.

     Sample inventory file with 3 dedicated controllers, 2 worker nodes, and 1 balancer.

  2. Follow the steps for distributed installation using your prepared k0s.inventory.yml inventory file.

  Migrating the KUMA Core to a new Kubernetes cluster

  When the installer is started with the inventory file, it looks for an installed KUMA Core on all hosts where you want to deploy worker nodes of the cluster. The found Core will be moved from the host to within the newly created Kubernetes cluster.

  If the component is not detected on the worker nodes, a clean installation of the KUMA Core is performed in the cluster without migrating resources to it. Existing components must be manually rebuilt with the new Core in the KUMA web interface.

  Certificates for collectors, correlators and storages will be re-issued from the inventory file for communication with the Core within the cluster. This does not change the Core URL for components.

  On the Core host, the installer does the following:

  • Removes the following systemd services from the host: kuma-core, kuma-mongodb, kuma-victoria-metrics, kuma-vmalert, and kuma-grafana.
  • Deletes the internal certificate of the Core.
  • Deletes the certificate files of all other components and deletes their records from MongoDB.
  • Deletes the following directories:
    • /opt/kaspersky/kuma/core/bin
    • /opt/kaspersky/kuma/core/certificates
    • /opt/kaspersky/kuma/core/log
    • /opt/kaspersky/kuma/core/logs
    • /opt/kaspersky/kuma/grafana/bin
    • /opt/kaspersky/kuma/mongodb/bin
    • /opt/kaspersky/kuma/mongodb/log
    • /opt/kaspersky/kuma/victoria-metrics/bin
  • Migrates data from the Core and its dependencies to a network drive within the Kubernetes cluster.
  • On the Core host, it migrates the following directories:
    • /opt/kaspersky/kuma/core → /opt/kaspersky/kuma/core.moved
    • /opt/kaspersky/kuma/grafana → /opt/kaspersky/kuma/grafana.moved
    • /opt/kaspersky/kuma/mongodb → /opt/kaspersky/kuma/mongodb.moved
    • /opt/kaspersky/kuma/victoria-metrics → /opt/kaspersky/kuma/victoria-metrics.moved

  After you have verified that the Core was correctly migrated to the cluster, these directories can be deleted.

  If you encounter problems with the migration, check the logs for records of the 'core-transfer' migration task in the 'kuma' namespace in the cluster (this task is available for 1 hour after the migration).

  If you need to perform migration again, you must convert the names of the /opt/kaspersky/kuma/*.moved directories back to their original format.

  If an /etc/hosts file with lines not related to addresses in the range 127.X.X.X was used on the Core host, the contents of the /etc/hosts file from the Core host is entered into the CoreDNS ConfigMap when the Core is migrated to the Kubernetes cluster. If the Core is not migrated, the contents of the /etc/hosts file from the host where the primary controller is deployed are entered into the ConfigMap.

Minimum configuration

There are 2 possible roles for nodes in Kubernetes:

• Controllers (control-plane). Nodes with this role manage the cluster, store metadata, and distribute the workload.
• Workers—nodes with this role bear the workload by hosting KUMA processes.

To perform a high availability installation of KUMA, you will need:

• 3 dedicated controllers
• 2 worker nodes
• 1 balancer

To ensure the adequate performance of KUMA Core in Kubernetes, it is critically important to allocate 3 dedicated nodes with a single controller role. This will provide high availability for the Kubernetes cluster and will ensure that the workload (KUMA processes and other processes) cannot affect the tasks associated with managing the Kubernetes cluster. If you are using virtualization tools, make sure that the nodes are located on different physical servers and that these physical servers do not act as worker nodes.

For a demo installation of KUMA, you may combine the controller and working node roles. However, if you are expanding an installation to a distributed installation, you must reinstall the entire Kubernetes cluster and allocate 3 dedicated nodes with the controller role and at least 2 nodes with the worker node role. KUMA cannot be upgraded to later versions if any of the nodes combine the controller and worker node roles.

In this section Additional requirements for deploying KUMA Core in Kubernetes Installing KUMA on a Kubernetes cluster from scratch Migrating the KUMA Core to a new Kubernetes cluster KUMA Core availability under various scenarios Managing Kubernetes and accessing KUMA Time zone in a Kubernetes cluster Managing KUMA web console certificates in a high availability configuration

Page top