Clea Astarte Operator
Clea Astarte Operator v26.7.0-rc.4

View Source Prerequisites

As much as Astarte's Operator is capable of creating a completely self-contained installation, there's a number of prerequisites to be fulfilled depending on the use case.

on-your-machine

 On your machine

The following tools are required within your local machine:

  • kubectl: must be compatible with your target Kubernetes version,
  • astartectl: your version must be the same of the Astarte Operator running in your cluster,
  • helm: v3 is required.

haproxy

 HAProxy

Astarte Operator is capable of interacting with HAProxy Ingress Controller through its dedicated AstarteDefaultIngress resource, as long as an HAProxy ingress controller is installed.

Please, be aware that trying to deploy multiple ingress controllers in your cluster may result in all of them trying simultaneously to handle the Astarte ingress resource. Consider using ingress classes for avoiding confusing situations as outlined here.

Helm installation via CLI Installing the ingress controller is as simple as running a few helm commands:

helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm install haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \
  --create-namespace \
  --namespace haproxy-controller \
  --set controller.service.externalTrafficPolicy=Local \
  --set controller.service.type=LoadBalancer \
  --set controller.service.enablePorts.quic=false

nginx

 NGINX

Starting from Astarte Operator v26.5.x, HAProxy is the default and preferred Ingress Controller for Astarte deployments. This is the last version of the Astarte Operator that will support NGINX as Ingress Controller due to Ingress NGINX retirement.

The annotation ingress.astarte-platform.org/ingress-controller-selector in the ADI CR can be used to specify which Ingress Controller the Astarte Operator should use.

By default, the Operator assumes the HAPROXY Ingress Controller is in use, in fact the annotation is set by default to:

ingress.astarte-platform.org/ingress-controller-selector: "haproxy.org"

If you want to still use NGINX, you will have to set the annotation to:

ingress.astarte-platform.org/ingress-controller-selector: "nginx.ingress.kubernetes.io"

Depending on the value of this annotation, the Operator will create Ingress resources compatible with the selected Ingress Controller.

cert-manager

 cert-manager

Astarte requires cert-manager to be installed in the cluster in its default configuration (installed in namespace cert-manager as cert-manager). If you are using cert-manager in your cluster already you don't need to take any action - otherwise, you will need to install it.

Astarte is actively tested with cert-manager 1.16.3, but should work with any 1.0+ releases of cert-manager. If your cert-manager release is outdated, please consider upgrading to a newer version according to this guide.

cert-manager documentation details all needed steps to have a working instance on your cluster. However, in case you won't be using cert-manager for other components beyond Astarte or, in general, if you don't have very specific requirements, it is advised to install it through its Helm chart. To do so, run the following commands:

$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ kubectl create namespace cert-manager
$ helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.16.3 \
  --set crds.enabled=true

This will install cert-manager and its CRDs in the cluster.

external-rabbitmq

 External RabbitMQ

Astarte needs a RabbitMQ instance to work. The Astarte Operator does not deploy a RabbitMQ instance: you must provision one before installing Astarte, then configure the connection details in the Astarte CR under the spec.rabbitmq section.

Tested RabbitMQ instances include:

external-cassandra-scylla

 External Cassandra / Scylla

Astarte relies on a Cassandra / Scylla database to work. The Astarte Operator does not deploy a Scylla DB instance: you must provision one before installing Astarte, then configure the connection details in the Astarte CR under the spec.cassandra section.

Refer to the Astarte Database documentation for further details.

external-hashicorp-vault-openbao

 External Hashicorp Vault / OpenBao

Astarte 1.4+ requires an external Hashicorp Vault or OpenBao instance to safely handle secrets. The Astarte Operator does not deploy a Hashicorp Vault or OpenBao instance: you must provision one before installing Astarte, then configure the connection details in the Astarte CR under the spec.vault section.

The configuration of a Vault is not supported when the selected Astarte version is 1.3.x

external-fdo-rendezvous-server

 External FDO Rendezvous Server

Astarte 1.4+ requires an external Rendezvous Server (RV) to provide the FDO (FIDO Device Onboard) feature. The Astarte Operator does not deploy a Rendezvous Server instance. If you plan to use FDO (optional on Astarte 1.3.x, mandatory on Astarte 1.4+), ensure to configure the Rendezvous Server instance connection details under spec.rendezvousServer on the Astarte CR.

kubernetes-and-external-components

 Kubernetes and external components

When deploying external components, it is important to take in consideration how Kubernetes behaves with the underlying infrastructure. Most modern Cloud Providers have a concept of Virtual Private Cloud, by which the internal Kubernetes Network stack directly integrates with their Network stack. This, in short, enables deploying Pods in a shared private network, in which other components (such as Virtual Machines) can be deployed.

This is the preferred, advised and supported configuration. In this scenario, there's literally no difference between interacting with a VM or a Pod, enabling a hybrid infrastructure without having to pay the performance cost.