Skip to main content
Version: 3.0

MaestroHub on Kubernetes

MaestroHub runs on Kubernetes in two shapes: one pod on one node, or replicated services across a cluster. This page compares them; each one has its own page with what it deploys, what it needs from the cluster and how it behaves when something fails.

Shapes
Single-node · High availability
Installed and upgraded by
Your platform team
High availability
Enterprise licence, 3 or more nodes
Run by your platform team

Your platform team installs MaestroHub's Helm charts, upgrades them and runs the cluster underneath. MaestroHub provides the charts and images and supports the MaestroHub application itself.

Two shapes​

Both shapes run the same product with the same features. What differs is how many copies run, and so what a failure costs. They are Tier 2 and Tier 3 in Deployment scenarios, which also lists the hardware for each.

Tier 2

Single-node

nodeMaestroHub · every moduleTimescaleDBPrometheus

The whole product in one pod: every module, the message bus and the MQTT broker in one process, the same as the binary.

Pods
MaestroHub, TimescaleDB, Prometheus
Nodes
One
Your cluster
Any distribution, one storage class
Upgrade
The pod is replaced, short outage
A failure
Kubernetes restarts the pod

Choose it when One plant or a small hub, where a restart of a few minutes is acceptable.

Single-node on Kubernetes

Tier 3

High availability

node 1module podsnatsdbsearchnode 2module podsnatsdbsearchnode 3module podsnatsdbsearch

Every module as its own service, most with two or more replicas, spread over the nodes and linked by a replicated NATS cluster.

Pods
Most modules ×2 or more, NATS ×3, TimescaleDB ×3, Elasticsearch ×3
Nodes
Three or more
Your cluster
Ingress, Postgres operator, storage, DNS and certificates; a backups bucket is recommended
Upgrade
Replicas replaced one at a time
A failure
Another replica takes over

Choose it when MaestroHub must keep running through the loss of a node, or the load is larger than one machine. Needs an Enterprise licence.

High availability on Kubernetes

Who is responsible for what​

High availability has two layers. MaestroHub's charts make the application survive the loss of a pod or a node: replicas, failover between them, and copies of the data on more than one node. The cluster and everything under it, the control plane, hosts, storage, network and power, is yours. If all the nodes share one hypervisor, one storage system or one switch, that is still a single point of failure, and no chart can make up for it.

Runs the installation

Your platform team

  • The Kubernetes cluster, its nodes and their upgrades
  • Installing and upgrading the MaestroHub charts
  • Hosts, storage, network and power, with the redundancy high availability needs underneath
  • Backups and restores
  • Ingress, DNS, certificates and Secrets
  • Monitoring the cluster and acting on its alerts
Supports the application

MaestroHub

  • The Helm charts and the container images
  • The MaestroHub application: its modules and how they behave
  • Problems in MaestroHub’s own services
  • Release notes and upgrade steps for every release