Getting started Community Training Tutorials Documentation APIs, AI & Tools
kubectl create ns rtf
You can use Helm to install Anypoint Runtime Fabric on an Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A), Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK), Google Kubernetes Engine (GKE), Oracle Kubernetes Engine (OKE), Rancher Kubernetes Engine (RKE) or VMware Tanzu Kubernetes Grid installation that you manage.
When you use Helm to install Runtime Fabric, you:
Create a Runtime Fabric using Runtime Manager
Create the rtf namespace for Runtime Fabric
Create a Docker pull secret for pulling the Runtime Fabric component images
Optionally, configure additional authorized namespaces
Add the Runtime Fabric Helm repository
Download the values.yml file and install Runtime Fabric
Complete install steps
Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have:
Reviewed the architecture and requirements outlined in the Runtime Fabric Overview.
Installed and configured your Kubernetes environment as follows:
Running an ACK, AKS, EKS, EKS-A, GKE, OKE, RKE, or VMware Tanzu Kubernetes environment. Other Kubernetes environments aren’t supported.
Running a supported Kubernetes version.
Running an ingress controller to send external requests to applications.
Installed Helm 3 or later and have privileged user permissions.
|
To install Runtime Fabric with Helm, first create a Runtime Fabric using Runtime Manager. This is required to obtain the activation data that is needed during installation.
From Anypoint Platform, select Runtime Manager.
Click Runtime Fabrics.
Click Create Runtime Fabric.
Enter the name of the new Runtime Fabric, then select one of these options:
Amazon Elastic Kubernetes Service
Azure Kubernetes Service
Google Kubernetes Engine
Oracle Kubernetes Engine
Review the Support responsibility disclaimer, and if you agree, click Accept.
Click Helm.
When creating the Runtime Fabric, the business unit you choose is set as the owner business unit. This business unit is referenced in usage reports for reporting allocated cluster capacity. Ensure that you select the correct business unit during installation.
|
The remaining steps in the Helm-install process reference placeholder values. You can retrieve the actual values from Runtime Manager when you create the Runtime Fabric instance. |
You must create a namespace named rtf in your Kubernetes cluster. This namespace is where you install Runtime Fabric components.
To create the namespace, run:
kubectl create ns rtf
Using rtf as a namespace applies only in the case of single cluster or single instance.
After you create the namespace, create a pull secret so you can retrieve the Docker images needed to install and run Runtime Fabric.
The registry URL depends on your control plane. Refer to the required parameters section for the rtfRegistry value for your region. If you’re using a local registry, specify those values here.
To create the pull secret, run:
kubectl create secret docker-registry <pull_secret> --namespace rtf --docker-server=<docker_registry_url> --docker-username=<docker_registry_username> --docker-password=<docker_ registry_password>
You need to add the Runtime Fabric Helm repo to the namespace you created. The Runtime Fabric Helm repo contains the chart needed to install Runtime Fabric.
To add the Helm repo, run:
helm repo add <name> <helm_repo_url> --username <your_username> --password <your_password>
|
If you already added the Helm repo, and you get a result that Runtime Fabric skipped adding the repo, run |
You can optionally configure authorized namespaces, which enable you to deploy Runtime Fabric alongside other services in a Kubernetes cluster.
Before configuring authorized namespaces, note the following:
You must create the authorized-namespaces ConfigMap file before installing Runtime Fabric. Additionally, you must name the ConfigMap, authorized-namespaces.
The rtf:resource-metrics-collector ClusterRole has cluster-wide permissions to get and list nodes, pods, and namespaces and has watch permissions for nodes. The role ClusterRole is defined as follows:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: rtf:resource-metrics-collector
labels:
{{- include "labels.standard" . | nindent 4 }}
rules:
- apiGroups: [""]
resources: ["nodes", "pods", "namespaces"]
verbs: ["list", "get"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["watch"]
In your cluster, create an additional namespace for application deployments, and add the necessary labels to the namespace. To do so, create a YAML file with the following contents:
apiVersion: v1
kind: Namespace
metadata:
name: <namespace>
labels:
rtf.mulesoft.com/agentNamespace: <rtf_namespace>
rtf.mulesoft.com/envId: <environment_id>
rtf.mulesoft.com/org: <org_id>
rtf.mulesoft.com/role: workers
Apply the file you just created:
kubectl apply -f <filename>.yaml
Repeat steps 1 and 2 to add as many namespaces as you need.
Create the RoleBinding for the Runtime Fabric agent ClusterRole that includes the Runtime Fabric agent ServiceAccount. To do so, apply the following configuration in your additional namespace:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <name>
namespace: <additional_namespace>
subjects:
- kind: ServiceAccount
name: rtf-agent
namespace: <rtf_namespace>
# If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces
# subjects:
# - kind: ServiceAccount
# name: rtf-persistence-gateway
# namespace: <rtf_namespace>
roleRef:
kind: ClusterRole
name: rtf:agent
apiGroup: rbac.authorization.k8s.io
To use clustered apps in authorized namespaces mode, the following RoleBinding must be created:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rtf-mule-clusterip-service
namespace: <app_namespace>
subjects:
- kind: ServiceAccount
name: mule-clusterip-service
namespace: <rtf_namespace>
roleRef:
kind: ClusterRole
name: rtf:mule-clusterip-service
apiGroup: rbac.authorization.k8s.io
In the rtf namespace, create a ConfigMap file named authorized-namespaces and list any additional namespaces:
apiVersion: v1
kind: ConfigMap
metadata:
name: authorized-namespaces
namespace: <rtf_namespace>
data:
ADDITIONAL_NAMESPACE_1: "additional-namespace1"
ADDITIONAL_NAMESPACE_2: "additional-namespace2"
If, after fully installing Runtime Fabric, you later add or delete any namespaces from the ConfigMap, you must restart the Runtime Fabric agent pod. To do so, run the following command:
kubectl -nrtf delete po -l app=agent
After you delete the pod, Kubernetes starts a new one.
To install Runtime Fabric, use the values.yml file supplied by Runtime Manager.
Download the values.yml file.
Add any optional parameters needed.
If you’re using authorized namespaces, set authorizedNamespaces to true.
Run the following command:
helm install runtime-fabric rtf/rtf-agent --version <VERSION_FROM_UI> -f values.yaml -n <namespace>
The following is an example values.yml file.
activationData: <activation_data>
proxy:
http_proxy:
http_no_proxy:
monitoring_proxy:
muleLicense: <mule_license_key>
customLog4jEnabled: false
global:
nodeWatcherEnabled: true
deploymentRateLimitPerSecond: 1
authorizedNamespaces: false
image:
rtfRegistry: rtf-runtime-registry.kqa.msap.io
pullSecretName: rtf-pull-secret
containerLogPaths:
- /var/lib/docker/containers
- /var/log/containers
- /var/log/pods
If you are configuring a Runtime Fabric BYOK for a non-US Cloud region (EU Cloud, Canada Cloud, Japan Cloud, India Cloud, or Australia Cloud), review the changes in Hostname Configuration for a correct configuration. Set the rtfRegistry property to the registry URL for your cloud region.
|
These required values are created and added to values.yml when you create the Runtime Fabric in Runtime Manager:
| Key | Value | Example |
|---|---|---|
|
Activation data |
YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ== |
|
Registry URL |
|
|
Registry secret |
|
|
Mule license for applications |
|
Set these optional parameters in values.yml as needed before installing Runtime Fabric.
| Key | Value | Example |
|---|---|---|
|
Enables or disables custom Log4j configurations |
|
|
Enables or disables additional namespaces |
|
|
Enables crds installations |
|
|
Proxy and no_proxy values |
|
|
Anypoint Monitoring proxy values |
|
|
The Filebeat read path |
|
|
Enables or disables node watcher for the cluster |
|
|
Sets the deployment rate limit per second |
|
|
Enable FIPS for Helm managed Runtime Fabrics. |
|
From Runtime Fabric version 2.11.0 onwards, you can configure these optional core software high availability parameters in the values.yml file. These are the default values:
global:
core:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
agent:
replicas: 1
app:
resources:
requests:
cpu: 100m
memory: 200Mi
limits:
cpu: 1000m
memory: 500Mi
rtfd:
resources:
requests:
cpu: 150m
memory: 200Mi
limits:
cpu: 200m
memory: 300Mi
mule-clusterip-service:
replicas: 1
resources:
requests:
cpu: 50m
memory: 100Mi
limits:
cpu: 500m
memory: 500Mi
resource-cache:
replicas: 1
nginx:
resources:
requests:
cpu: 100m
memory: 50Mi
limits:
cpu: 500m
memory: 250Mi
fetcher:
resources:
requests:
cpu: 50m
memory: 50Mi
limits:
cpu: 50m
memory: 100Mi
For each Runtime Fabric deployment (agent, resource-cache, and mule-clusterip-service), you can configure the resources and the number of replicas.
In the case of agent deployments, having multiple replicas doesn’t increase the throughput it can manage. However, if the leading pod encounters an issue, one of the remaining replicas takes the lead and continues to serve traffic.
By modifying the topologySpreadConstraints object, you can control how the replicas for each deployment are distributed across the cluster nodes.
You can also use global.core.affinity to apply Kubernetes affinity and anti-affinity rules to Runtime Fabric core service pods. Use this to control node affinity, pod affinity, or pod anti-affinity for Runtime Fabric components. For example, to restrict core pods to amd64 nodes:
global:
core:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- amd64
| If you configure these values and then roll back a Runtime Fabric instance to a previous version, the configuration isn’t applied to the older version. |
If you didn’t add the Mule license key during install, you can add it using the rtfctl command line utility or Helm.
Before you install the license key, encode it to Base64 format.
On MacOS, run the following command:
base64 -b 0 -i <license-file>
On Unix, run the following command:
base64 -w0 <license-file>
On Windows, choose one of the following:
Use a WSL or Cygwin shell that includes the base64 tool and use the above Unix command.
Use the base64.exe program included with Windows git (C:\Program Files\Git\usr\bin).
Use the following Powershell command:
$BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte))
On the controller node acting as the leader during installation (the installer node), run the following command:
rtfctl apply mule-license $BASE64_ENCODED_LICENSE
You can also apply the Mule license providing the file path directly:
rtfctl apply mule-license --file /path/to/license.lic
Any value used with rtfcl apply updates does not work for OpenShift. You have to update the values in the OpenShift console.
|
To verify the Mule license key has applied correctly, run:
rtfctl get mule-license
If your ingress controller requires custom annotations and ingress class definition, follow the instructions in Defining a Custom Ingress Configuration.
|
For GKE customers, the ingress controller included with GKE will provision a separate HTTP load balancer per application by default. |
After completing the installation, your Runtime Fabric should be activated within your Anypoint organization. To validate your installation, go to Anypoint Runtime Manager and confirm that the status of the Runtime Fabric is Active.
Before deploying an application to your Runtime Fabric:
Associate the Runtime Fabric with at least one Anypoint environment.
Review and update the Inbound Traffic settings based upon your Kubernetes environment.
Deploy an application to verify that Runtime Fabric is installed and configured correctly.
To roll back to a previous version of Runtime Fabric using helm, refer to the Helm rollback documentation for the command description.
To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a bearer token for authentication:
Replace <ORG_ID> with your organization’s ID, and <ANYPOINT_PLATFORM_URL> with your Anypoint Platform region URL.
The API response has this structure:
{
"RTF_IMAGE_REGISTRY_ENDPOINT": "rtf-runtime-registry.kprod.msap.io",
"RTF_IMAGE_REGISTRY_USER": "username/us-east-1/truncated",
"RTF_IMAGE_REGISTRY_PASSWORD": "Truncated"
}
The URL for the Helm repository containing the Helm charts is constructed as follows:
{RTF_IMAGE_REGISTRY_ENDPOINT}/charts.
For example:
US Cloud: rtf-runtime-registry.kprod.msap.io/charts
EU Cloud: rtf-runtime-registry.kprod-eu.msap.io/charts
Canada Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net/charts
Japan Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net/charts
India Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net/charts
Australia Cloud: rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net/charts