Setting up a Kubernetes Cluster

This guide describes how to set up a Kubernetes cluster which can be used to run Eclipse Hono™.

Hono can be deployed to any Kubernetes cluster running version 1.11 or newer. This includes OpenShift (Origin) which is built on top of Kubernetes.

The Kubernetes web site provides instructions for setting up a (local) cluster on bare metal and/or virtual infrastructure from scratch or for provisioning a managed Kubernetes cluster from one of the popular cloud providers.

Setting up a local Development Environment

The easiest option is to set up a single-node cluster running on a local VM using the Minikube project. This kind of setup is sufficient for evaluation and development purposes. Please refer to Minikube’s getting started guide for instructions on how to set up a cluster locally.

The recommended settings for a Minikube VM used for running Hono’s example setup are as follows:

  • cpus: 2
  • memory: 8192 (MB)

The command to start the VM will look something like this:

minikube start --cpus 2 --memory 8192

After the Minikube VM has started successfully, the minikube tunnel command should be run in order to support Hono’s services being deployed using the LoadBalancer type. Please refer to the Minikube Loadbalancer docs for details.


Minikube will use the most recent Kubernetes version that was available when it has been compiled by default. Hono should run on any version of Kubernetes starting with 1.13.6. However, it has been tested with several specific versions only. The most recent version known to work is 1.15.4 so if you experience any issues with running Hono on another version, please try to deploy to 1.15.4 before raising an issue. You can use Minikube’s --kubernetes-version command line switch to set a particular version.

Setting up a Production Environment

Setting up a multi-node Kubernetes cluster is a more advanced topic. Please follow the corresponding links provided in the Kubernetes documentation.

Setting up an Environment on Microsoft Azure

This chapter describes how Hono can be deployed on Microsoft Azure. It includes:


This deployment model is not meant for productive use but rather for evaluation as well as demonstration purposes or as a baseline to evolve a production grade Application architecture out of it which includes Hono.



As described here we will create an explicit service principal. Later we add roles to this principal to access the Azure Container Registry (ACR).

# Create service principal
service_principal=`az ad sp create-for-rbac --name http://honoServicePrincipal --skip-assignment --output tsv`
app_id_principal=`echo $service_principal | cut -f1 -d ' '`
password_principal=`echo $service_principal | cut -f4 -d ' '`
object_id_principal=`az ad sp show --id $app_id_principal --query objectId --output tsv`

Note: it might take a few seconds until the principal is available for the next steps.

Now we create the Azure Container Registry instance and provide read access to the service principal.

# Resource group where the ACR is deployed.
# Name of your ACR.
# Full name of the ACR.

az acr create --resource-group $acr_resourcegroupname --name $acr_registry-name  --sku Basic
acr_id_access_registry=`az acr show --resource-group $acr_resourcegroupname --name $acr_registry_name --query "id" --output tsv`
az role assignment create --assignee $app_id_principal --scope $acr_id_access_registry --role Reader

With the next command we will use the provided Azure Resource Manager (ARM) templates to setup the AKS cluster. This might take a while.

az group create --name $resourcegroup_name --location "westeurope"
cd deploy/src/main/deploy/azure/
az group deployment create --name HonoBasicInfrastructure --resource-group $resourcegroup_name --template-file arm/honoInfrastructureDeployment.json --parameters uniqueSolutionPrefix=$unique_solution_prefix servicePrincipalObjectId=$object_id_principal servicePrincipalClientId=$app_id_principal servicePrincipalClientSecret=$password_principal


  • add the following parameter in case you want to opt for the Azure Service Bus as broker in the Hono AMQP 1.0 Messaging Network instead of deploying a (self-hosted) ActiveMQ Artemis into AKS: serviceBus=true
  • add the following parameter to define the k8s version of the AKS cluster. The default as defined in the template might not be supported in your target Azure region, e.g. kubernetesVersion=1.14.6

After the deployment is complete you can set your cluster in kubectl.

az aks get-credentials --resource-group $resourcegroup_name --name $aks_cluster_name

Next create retain storage for the device registry.

kubectl apply -f managed-premium-retain.yaml

Now Hono can be installed to the AKS cluster as describe in the Helm based installation guide.


You can monitor your cluster using Azure Monitor for containers.

Navigate to -> your resource group -> your kubernetes cluster

On an overview tab you fill find an information about your cluster (status, location, version, etc.). Also, here you will find a Monitor Containers link. Navigate to Monitor Containers and explore metrics and statuses of your Cluster, Nodes, Controllers and Containers.

Cleaning up

Use the following command to delete all created resources once they are no longer needed:

az group delete --name $resourcegroup_name --yes --no-wait