How to run Mulesoft Anypoint Runtime Fabric on minikube

Anypoint Runtime Fabric (RTF) is the Mulesoft product for running integration applications and managed APIs in Kubernetes clusters.

There are two supported ways of running Runtime Fabric: (1) RTF on self-managed Kubernetes, where the customer provisions a cluster on Amazon Web Services, Microsoft Azure or Google Cloud Platform and (2) Runtime Fabric on VMs / Bare Metal where the customer provides (virtual) machines and the installation of a Kubernetes cluster is part of the distribution provided by Mulesoft.

Sometimes it can be helpful to test things out locally, even if it is just to satisfy one’s own curiosity. For Kubernetes applications a way to do this is minikube. Minikube is a k8s distribution that spins up a cluster on the local development machine. So it is a logical next step to try out Runtime Fabric on a local machine using minikube.

How does it work

This article uses RTF on Self-Managed Kubernetes. The Kubernetes cluster is provided by minikube. Mulesoft provides the rtfctl command-line utility, which is used to install RTF on the cluster a local installation of kubectl is configured to use. The deployment of RTF is managed by the tool and no manual steps are needed. The cluster then registers itself with the Control Plane of Anypoint Platform. When deploying an application the cluster can then be selected as a regular deployment target.

Prerequisites

• Minikube needs to be installed locally, instructions can be found here .
• The rtfctl utility needs to be downloaded from Mulesoft, instructions can be found here .
• To be able to start applications inside the cluster, a Mulesoft licence key that allows for RTF needs to be available.

Set-up and installation

Start minikube-cluster

After installing minikube, a new cluster can be created with the start command:

minikube start -p rtf --kubernetes-version=1.21.11 --nodes 2

As per documentation RTF should have at least 2 nodes available to run properly. The compatible Kubernetes versions can be found on the Mulesoft website. The -p argument allows the creation of multiple independent clusters on the same local machine, rtf is the name of our cluster.

Start Kubernetes dashboard

Start the Kubernetes dashboard for easy access to what is going on inside the cluster:

minikube dashboard -p rtf

This command starts the Kubernetes dashboard inside the cluster, makes it available from the host machine and opens it inside the browser.

Create Monitoring namespace

Before starting the installation, a namespace named ‘monitoring’ needs to be created inside the cluster:

kubectl create namespace monitoring

Add master node label

The following label needs to be applied to at least one node inside the cluster using the kubectl utility:

kubectl label nodes rtf node-role.kubernetes.io/master=true --overwrite=true

Notice that the name of the node (rtf in the example above) corresponds to the cluster name set via -p when creating the cluster. If -p wasn’t used, there is a node named minikube that can be labeled.

Create new rtf in Runtime Manager

In order to be able to deploy to the local RTF cluster from Anypoint Platform, the new RTF needs to be set-up inside the web interface.
After signing in to Anypoint Platform, select Runtime Manager in the main menu and select Runtime Fabrics in the sidebar (the organisation needs to be licensed to use RTF by Mulesoft).
When creating the cluster the user has to select a cloud provider or must use RTF on VMs/bare metal. For minikube, selecting AWS as cloud provider seems to work.
After naming the newly created RTF, an activation code is displayed:

Install rtf inside the cluster

To install RTF with the rtfctl utility just run the install command with the activation code provided by runtime manager (the executable is run locally without ‘installing’ it):

./rtfctl install --force-reinstall [activation code]

The –force-reinstall parameter can be used, if rtfctl has been used before and stops with a message that the installation has already been performed.

The installation is waiting for the pods to come up. In the Kubernetes dashboard the status of the deployments can be seen:

When the deployments are successful and shown with a green light in the Kubernetes dashboard the installation is completed.
The job cluster-status is run inside the cluster to gather information about the cluster and send it to the Anypoint Platform control plane. The results of this job are saved to the cluster-status-output Config Map in the rtf namespace.

Apply license

In order to successfully start, Mule applications need a valid license. The license is injected into the cluster with the rtfctl utility, as described by Mulesoft here, and is then provided to the application pods.

What Mulesoft does not mention on the documentation page is that on windows you can either use WSL to read the license into a variable

BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic)

or use Powershell to achieve this like so:

$BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte))

After doing that you can apply the license using this variable – the syntax for Powershell and Unix is the same:

./rtfctl apply mule-license $BASE64_ENCODED_LICENSE

Associate environment

In Runtime Manager an environment needs to be associated with the cluster in order to be able to select the cluster, when deploying applications:

Deploy app

As a result, the cluster should appear in the list of deployment targets when Deploying an app via Runtime Manager → Applications as usual.

Ingress

In the real world, an ingress template in conjunction with Runtime manager would be used to configure internet-facing access to Mule applications. For testing a local load balancer (option A) or a node port service (option B) is sufficient.

Option A: LoadBalancer + minikube tunnel

Create a LoadBalancer service inside the namespace that rtf has created for the deployed mule app:

kubectl expose deployment test --type=LoadBalancer --port=8081 --name=test-svc -n d57e0146-0045-4f9a-88bb-7811bf599c3e

Test has to be replaced with the name of the deployed application. The –name parameter sets the name of the service, which cannot be the same as the deployed application (because RTF automatically created a service with that name). The -n sets the namespace to the one RTF has automatically created when the application was deployed. It can be observed in the dashboard or via kubectl.

Kubectl or the dashboard can be used to observe the external IP address of the newly created LoadBalancer:

kubectl get service --all-namespaces

To be able to access the LoadBalancer from the local machine, minikube offers a tunnel functionality:

minikube tunnel

Then the Mule application is reachable on the external IP address of the LoadBalancer using the set port. The tunnel needs to stay running as long as the application is accessed.

Option  B: NodePort + minikube service

Alternatively the application can be accessed without using the minikube tunnel by creating a NodePort service:

kubectl expose deployment test --type=NodePort --name=test-svc -n d57e0146-0045-4f9a-88bb-7811bf599c3e

The minikube service command then tells minikube to map the NodePort inside the cluster to the local host machine:

minikube service test-svc -p rtf -n d57e0146-0045-4f9a-88bb-7811bf599c3e

Subsequently the output of this command shows to which ports on the external IP of the cluster the mule port  is mapped to. This usually is port 8081.

An upside of this approach is that there is no need to keep the tunnel running or manually start it, after restarting the minikube cluster. The tradeoff is that a non-standard port number which has been randomly assigned by k8s has to be remembered. Additionally, load-balancing cannot be configured with this approach.

It is important to note that running Runtime Fabric on minikube is in no way endorsed or supported by Mulesoft and could break at any time. The steps outlined here are just a way to set up a quick and rough local testing environment for RTF, without having to use a real cloud vendor to create a Kubernetes cluster or set up VMs manually.