Multiarchitecture support

Overview

Previously Kublr used the kublrAgentTgzUrl definition to specify the full path to the Kublr agent binary (version folder and particular architecture file). For example:

spec:
  kublrAgentTgzUrl: https://repo.kublr.com/repository/gobinaries/kublr/1.22.17-4/kublr-1.22.17-4-linux.tar.gz
  kublrSeederTgzUrl: https://repo.kublr.com/repository/gobinaries/kublr/1.25.6-4/kublr-1.25.6-4-linux.tar.gz

Now the kublrAgentTgzUrl definition is deprecated - starting from v1.25.0 Kublr is moving to a structured annotation: only versions of Kublr agent components are specified and a built-in logic decides which architecture to use:

spec:
  kublrAgentBinary:
    kublrAgentRef: 1.22.17-4
  kublrSeederBinary:
    kublrAgentRef: 1.25.6-4

Thus the new approach provides support for multiarchitecture as depending on the instance architecture, the corresponding architecture binary is automatically selected.

Multiarchitecture advantages

Kublr multiarchitecture support includes:

Support of the ARM64 architecture in all Kublr components, which allows using the appropriate types of computing resources to create clusters, which in turn saves on infrastructure costs with equal performance.
Support for hybrid clusters which is important for migrating of workloads to the ARM64 architecture. Hybrid clusters are supported in all combinations.
Kublr agent’s compatibility with the agents both without and with multiarchitecture support.
The agent registration procedure.
User interface (UI). Starting from v1.26.0, multiarchitecture clusters or platforms can be created via UI for AWS: you can create both cluster and platform.
User experience (UX). For cloud providers other than AWS, multiarchitecture clusters and platforms can be created through a cluster specification.
Logging and Monitoring (1.26.0). When using the default version of ELK 7.10.2 which does not have multi-architecture support in a hybrid cluster, an amd64 node group must be provided. The alternative version ELK 7.17.9 with multi-architecture support is added. It can be enabled via cluster specification.

NOTE Multiarchitecture support is a functionality under development and will be further improved in the next releases of Kublr.

Examples

GCP

Consider the following steps to create a cluster with ARM nodes in GCP:

For GCP, select the ARM instances (t-series), for example t2a-standard-2, t2a-standard-4:
```
instanceType: t2a-standard-2
```

For the OS, change the sourceImage to ARM type:

sourceImage: projects/ubuntu-os-cloud/global/images/family/ubuntu-2204-lts-ARM64

GCP cluster - ARM source images for master and working nodes

Azure

Consider the following steps to create a cluster with ARM nodes in Azure:

Select the ARM instances like Standard_D4ps_v5, Standard_D4pls_v5 and modify spec as follows:
```
imageSku: 22_04-lts-ARM64 
```
This is set both for master and working nodes if they both use ARM.