–

Single-server installation or distributed installation with one KUMA Core service

Performed automatically by the installer. The inventory file used is similar to the inventory file of version 3.4.x. The KUMA Core service on a host specified in the kuma_core section has the name 'core-1' and the ID 00000000-0000-0000-0000-000000000000.

–

Single-server installation with KUMA Core in a Raft cluster or distributed installation with KUMA Core in a Raft cluster

Performed automatically by the installer. The installer prepares hosts from the additional kuma_core_peers section, automatically creates additional KUMA Core services, and includes these in the Raft cluster by installing them on hosts from this section. The KUMA Core service on a host from the kuma_core section has the name 'core-1' and the ID 00000000-0000-0000-0000-000000000000. The KUMA Core services on hosts from the kuma_core_peers section have names of the 'core- <host_name_in_inventory_file>' form and unique IDs.

Creating a Raft cluster in a 4.xx installation with one KUMA Core service

You can configure additional hosts using the expand.sh installer and the expand.inventory.yml inventory file with a kuma_core_peers section. After that, you need to create additional KUMA Core services in the KUMA web interface and use the installation command to install the KUMA Core services on the prepared hosts, one host at a time.

Single-server installation or distributed installation

Single-server installation with one KUMA Core service in a Raft cluster or distributed installation with one KUMA Core service in a Raft cluster

Performed automatically by the installer. The inventory file used is similar to the 3.4.X inventory. The name and ID of the KUMA Core service on a host from the kuma_core section are not changed.

Single-server installation or distributed installation

Single-server installation with multiple KUMA Core services in a Raft cluster or distributed installation with multiple KUMA Core services in a Raft cluster

Each KUMA Core service must be hosted on a separate host. The installer only prepares hosts from the additional kuma_core_peers section for the subsequent manual installation of additional KUMA Core services. After upgrading to version 4.x.x, you need to create additional KUMA Core services in the KUMA web interface, which are then automatically added to the cluster. If necessary, you can configure additional hosts after the upgrade using the expand.sh installer and the expand.inventory.yml inventory file, create KUMA Core services in the KUMA web interface, install KUMA Core services on additional hosts, and include services in the cluster.

During the upgrade, the kuma_core and kuma_core_peers sections are checked for uniqueness of hosts, similar to installing from scratch. If you populated the kuma_core_peers section during the upgrade, the actions that the install.sh installer performs for it are similar to the actions performed by the individual launch of the expand.sh installer.

–

Installing a single KUMA Core service on a Kubernetes cluster

You can install the KUMA Core service as one instance with two volume replicas. You can use an inventory file similar to version 3.4.x. For high availability, you need at least two worker nodes.

Installation with KUMA Core in a Kubernetes cluster

Installation with a single KUMA Core service on a Kubernetes cluster

The KUMA Core service stays as one instance with two volume replicas. The inventory file used is similar to the inventory file of version 3.4.x.

Multiple KUMA Core services are not supported in 4.x.x.

Migrating a 4.x.x installation with one KUMA Core service to an installation with one KUMA Core service in a Kubernetes cluster

The procedure is similar to migration to a high-availablity installation in previous versions of KUMA.

You can install the KUMA Core service as one instance with two volume replicas. The inventory file used is similar to the inventory file of version 3.4.x. For high availability, you need at least two worker nodes. The host of the KUMA Core service becomes one of the worker nodes of the cluster.