---
schema_version: "1"
id: 4cf17d63287f18b2793dd717f0bb379d14733f184c34f771708a27c8664f3da6
title: Installing Runtime Fabric Using Helm
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/runtime-fabric/latest/install-helm.md
canonical_url: https://docs.mulesoft.com/runtime-fabric/latest/install-helm
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 146a9fcd887524755ed9c49b49c74f54c49fefa1b0b62cacdecdb604740057c2
description: MuleSoft Documentation Site
release: "3.0"
latest: true
---
---
product: Runtime Fabric
version: 3.0
is-latest-version: true
---

# Installing Runtime Fabric Using Helm

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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.

## Steps to Install Runtime Fabric Using Helm

When you use Helm to install Runtime Fabric, you:

1.  Create a Runtime Fabric using Runtime Manager

2.  Create the `rtf` namespace for Runtime Fabric

3.  Create a Docker pull secret for pulling the Runtime Fabric component images

4.  Optionally, configure additional authorized namespaces

5.  Add the Runtime Fabric Helm repository

6.  Download the `values.yml` file and install Runtime Fabric

7.  Complete install steps

## Before you Begin

Before installing Anypoint Runtime Fabric in a Kubernetes environment, ensure that you have:

- Reviewed the architecture and requirements outlined in the [Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/latest/).

- [Configured your network to support Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration).

- 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.

> [!IMPORTANT]
>
> - If you use Helm to manage your Runtime Fabric installation, you can use the `rtfctl` command
>   line utility later to manage Mule license keys and proxies. However, you’ll need to track any
>   post-installation changes you make, as explained in the [upgrade documentation](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-helm).

### Helm Support

Runtime Fabric supports installations, upgrades, and rollbacks using Helm for versions 2.0 and
later.

## Create a Runtime Fabric Using Runtime Manager

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.

1.  From Anypoint Platform, select Runtime Manager.

2.  Click **Runtime Fabrics**.

3.  Click **Create Runtime Fabric**.

4.  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

5.  Review the Support responsibility disclaimer, and if you agree, click **Accept**.

6.  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.

> [!NOTE] 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.

## Create A Namespace for Runtime Fabric

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:

```copy
kubectl create ns rtf
```

Using `rtf` as a namespace applies only in the case of single cluster or single instance.

## Create A Docker Pull Secret

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](#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:

```copy
kubectl create secret docker-registry <pull_secret> --namespace rtf --docker-server=<docker_registry_url> --docker-username=<docker_registry_username> --docker-password=<docker_ registry_password>
```

## Add the Runtime Fabric Helm Repository

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:

```copy
helm repo add <name> <helm_repo_url> --username <your_username> --password <your_password>
```

> [!NOTE] If you already added the Helm repo, and you get a result that Runtime Fabric skipped
> adding the repo, run `helm repo update` before installing, or upgrading to, a new Runtime Fabric
> version.

## (Optional) Configure Authorized Namespaces

You can optionally configure [authorized namespaces](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces), which enable you to
deploy Runtime Fabric alongside other services in a Kubernetes cluster.

### Before You Begin

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"\]
  1.  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:

      ```copy
      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
      ```

  2.  Apply the file you just created:

      ```copy
      kubectl apply -f <filename>.yaml
      ```

  3.  Repeat steps 1 and 2 to add as many namespaces as you need.

  4.  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:

      ```copy
      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:

```yaml
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
```

5.  In the `rtf` namespace, create a ConfigMap file named `authorized-namespaces` and list any
    additional namespaces:

    ```copy
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: authorized-namespaces
      namespace: <rtf_namespace>
    data:
      ADDITIONAL_NAMESPACE_1: "additional-namespace1"
      ADDITIONAL_NAMESPACE_2: "additional-namespace2"
    ```

6.  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:

    ```copy
    kubectl -nrtf delete po -l app=agent
    ```

    After you delete the pod, Kubernetes starts a new one.

## Install Runtime Fabric

To install Runtime Fabric, use the `values.yml` file supplied by Runtime Manager.

1.  Download the `values.yml` file.

2.  Add any optional parameters needed.

    If you’re using authorized namespaces, set `authorizedNamespaces` to `true`.

3.  Run the following command:

    ```copy
    helm install runtime-fabric rtf/rtf-agent --version <VERSION_FROM_UI> -f values.yaml -n <namespace>
    ```

## Values.yml Reference

The following is an example `values.yml` file.

```yaml
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
```

> [!NOTE] If you are configuring a Runtime Fabric BYOK for a non-US Cloud region (EU Cloud, Canada
> Cloud, Japan Cloud, India Cloud, Australia Cloud, or United Kingdom Cloud), review the changes in
> [Hostname Configuration](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed-network-configuration#hostname-configuration) for a
> correct configuration. Set the `rtfRegistry` property to the registry URL for your cloud region.

### Required Parameters

These required values are created and added to `values.yml` when you create the Runtime Fabric in
Runtime Manager:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Key</th><th>Value</th><th>Example</th></tr></thead><tbody><tr><td><p><code>activationData</code></p></td><td><p>Activation data</p></td><td><p>YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==</p></td></tr><tr><td><p><code>rtfRegistry</code></p></td><td><p>Registry URL</p></td><td><div><div><ul><li><p>US: <code>rtf-runtime-registry.kprod.msap.io</code></p></li><li><p>EU: <code>rtf-runtime-registry.kprod-eu.msap.io</code></p></li><li><p>Canada: <code>rtf-runtime-registry-mulesoft-cp.sfdc-58ktaz.svc.sfdcfc.net</code></p></li><li><p>Japan: <code>rtf-runtime-registry-mulesoft-cp.sfdc-mchho0.svc.sfdcfc.net</code></p></li><li><p>India Cloud: <code>rtf-runtime-registry-mulesoft-cp.sfdc-y37hzm.svc.sfdcfc.net</code></p></li><li><p>Australia Cloud: <code>rtf-runtime-registry-mulesoft-cp.sfdc-vwfla6.svc.sfdcfc.net</code></p></li><li><p>United Kingdom Cloud: <code>rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net</code></p></li></ul></div></div></td></tr><tr><td><p><code>pullSecretName</code></p></td><td><p>Registry secret</p></td><td><p><code>&lt;pull_secret&gt;</code></p></td></tr><tr><td><p><code>muleLicense</code></p></td><td><p>Mule license for applications</p></td><td><p><code>&lt;mule_license_key&gt;</code>. Must be Base64 encoded.</p></td></tr></tbody></table>

### Optional Parameters

Set these optional parameters in `values.yml` as needed before installing Runtime Fabric.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Key</th><th>Value</th><th>Example</th></tr></thead><tbody><tr><td><p><code>customLog4jEnabled</code></p></td><td><p>Enables or disables custom Log4j configurations</p></td><td><p><code>customLog4jEnabled: true</code>, default is <code>false</code></p></td></tr><tr><td><p><code>authorizedNamespaces</code></p></td><td><p>Enables or disables additional namespaces</p></td><td><p><code>authorizedNamespaces: true</code>, default is false</p></td></tr><tr><td><p><code>crds.install</code></p></td><td><p>Enables crds installations</p></td><td><p><code>crds.install: true</code>, for first Runtime Fabric installation and false for subsequent installations</p></td></tr><tr><td><div><div><ul><li><p><code>proxy.http_proxy</code></p></li><li><p><code>proxy.http_no_proxy</code></p></li></ul></div></div></td><td><p>Proxy and no_proxy values</p></td><td><div><div><ul><li><p><code><a href="http://&lt;user&gt;:&lt;pass&gt;@&lt;10.0.0.1&gt;:&lt;8080&gt;">http://&lt;user&gt;:&lt;pass&gt;@&lt;10.0.0.1&gt;:&lt;8080&gt;</a>;</code></p></li><li><p><code>&lt;1.1.1.1:8888,2.2.2.2:9999&gt;</code></p></li></ul></div></div></td></tr><tr><td><p><code>proxy.monitoring_proxy</code></p></td><td><p>Anypoint Monitoring proxy values</p></td><td><p><code>socks5://&lt;user&gt;:&lt;pass&gt;@&lt;10.0.0.2&gt;:&lt;8080&gt;</code></p></td></tr><tr><td><p><code>global.containerLogPaths</code></p></td><td><p>The Filebeat read path</p></td><td><div><div><ul><li><p><code>/var/lib/docker/</code></p></li><li><p><code>/var/log/containers</code></p></li><li><p><code>/var/log/pods</code></p></li></ul></div></div></td></tr><tr><td><p><code>nodeWatcherEnabled</code></p></td><td><p>Enables or disables node watcher for the cluster</p></td><td><p><code>nodeWatcherEnabled:true</code> default value <code>true</code></p></td></tr><tr><td><p><code>deploymentRateLimitPerSecond</code></p></td><td><p>Sets the deployment rate limit per second</p></td><td><p><code>deploymentRateLimitPerSecond: 1</code> default value <code>1</code></p></td></tr><tr><td><p><code>fipsEnabled</code></p></td><td><p>Enable FIPS for Helm managed Runtime Fabrics.</p></td><td><p><code>fipsEnabled: true</code> default value <code>false</code></p></td></tr></tbody></table>

### Configure Core Software High Availability Parameters

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:

```yaml
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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#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:

```yaml
global:
  core:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/arch
                  operator: In
                  values:
                    - amd64
```

> [!NOTE] 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.

## Insert the Mule License Key

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.

### Encode the License Key

- On MacOS, run the following command:

  ```copy
  base64 -b 0 -i <license-file>
  ```

- On Unix, run the following command:

  ```copy
  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:

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

### Apply the License Key Using rtfctl

1.  On the controller node acting as the leader during installation (the installer node), run the
    following command:

    ```copy
    rtfctl apply mule-license $BASE64_ENCODED_LICENSE
    ```

    You can also apply the Mule license providing the file path directly:

    ```copy
    rtfctl apply mule-license --file /path/to/license.lic
    ```

    > [!NOTE] Any value used with `rtfcl apply` updates does not work for OpenShift. You have to
    > update the values in the OpenShift console.

2.  To verify the Mule license key has applied correctly, run:

    ```copy
    rtfctl get mule-license
    ```

### Apply the License Key Using Helm

To apply the license using Helm, run the following command:

```copy
helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version <current-version>
```

## Configure the Ingress Resource Template

If your ingress controller requires custom annotations and ingress class definition, follow the
instructions in [Defining a Custom Ingress Configuration](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration).

> [!NOTE] For GKE customers, the ingress controller included with GKE will provision a separate HTTP
> load balancer per application by default.

## Validate Your Runtime Fabric

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:

1.  Associate the Runtime Fabric with at least one Anypoint environment.

2.  Review and update the Inbound Traffic settings based upon your Kubernetes environment.

3.  Deploy an application to verify that Runtime Fabric is installed and configured correctly.

## Perform a Rollback

To roll back to a previous version of Runtime Fabric using helm, refer to the
[Helm rollback](https://helm.sh/docs/helm/helm_rollback/) documentation for the command description.

## Retrieve Helm Registry Endpoints and Credentials

To obtain the Helm registry endpoints and credentials, make a request to this API endpoint using a
bearer token for authentication:

`[https://<ANYPOINT_PLATFORM_URL>/runtimefabric/api/organizations/<ORG_ID>/helmrepoproperties](https://\<ANYPOINT_PLATFORM_URL\>/runtimefabric/api/organizations/\<ORG_ID\>/helmrepoproperties)`

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`

- United Kingdom Cloud: `rtf-runtime-registry-mulesoft-cp.sfdc-5pakla.svc.sfdcfc.net/charts`

## See Also

- [Configure Ingress for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/custom-ingress-configuration)

- [Deploy a Mule Application to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)
