---
schema_version: "1"
id: e977edfd9049801f28821c0e13a55b7c1c1ccd4903cfa893ad78f9af061fce85
title: Installing Multiple Instances of Runtime Fabric on a Single Cluster
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/runtime-fabric/2.11/install-multiple-instances.md
canonical_url: https://docs.mulesoft.com/runtime-fabric/2.11/install-multiple-instances
source_site: docs.mulesoft.com
content_type: documentation
content_hash: df28455167a25a1ac4807ed7a6222e9d934408a096089113e02b4ce6463d284f
description: MuleSoft Documentation Site
release: "2.11"
latest: false
---
---
product: Runtime Fabric
version: 2.11
---

# Installing Multiple Instances of Runtime Fabric on a Single Cluster

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

Installing multiple instances of Anypoint Runtime Fabric enables you to share the same cluster among
multiple Runtime Fabrics, which helps you to use resources efficiently.

- To use this feature, you must upgrade to the minimum version of 2.2.5 of the Runtime Fabric agent
  that supports multiple instances.

- Agent namespaces map one-to-one to app namespaces. You cannot share app namespaces amongst
  multiple instances of Runtime Fabric on the same cluster.

> [!NOTE] For multiple instances, the first Runtime Fabric agent installation creates a custom
> resource definition (CRD) for `persistencegateways.rtf.mulesoft.com` and priority class
> `rtf-components-high-priority` resources. Runtime Fabric agent doesn’t clean up these resources
> when you uninstall the agent.

## Install Multiple Instances of Runtime Fabric

To install multiple instances of Anypoint Runtime Fabric on a single BYOK (Bring Your Own
Kubernetes) cluster, follow these steps:

1.  Create a Runtime Fabric using Runtime Manager.

2.  Create a custom namespace to install the Fabric created in the previous step:

    kubectl create ns <rtf\_namespace>

3.  Create a Docker pull secret to pull the Runtime Fabric component images for the previously
    created namespace:

    kubectl create secret docker-registry rtf-pull-secret --namespace <rtf\_namespace>
    --docker-server=<docker\_registry\_url> --docker-username=<docker\_registry\_username>
    --docker-password=<docker\_ registry\_password>

4.  Add the Runtime Fabric helm repository:

    helm repo add <name> <helm\_repo\_url> --username <your\_username> --password <your\_password>

5.  Optionally, you can configure the shared tenancy. Refer to
    [Configure Authorized Namespaces](#configure-namespaces) for details.

6.  Download and configure the `values.yaml` file from the Anypoint Platform UI.

7.  Set the [required parameters](#required-parameters) for the `values.yaml` file.

8.  Install Runtime Fabric on the cluster:

    helm install runtime-fabric rtf/rtf-agent --version <rtf\_version> -f values.yaml -n
    <rtf\_namespace>

## Values.yaml File Required Parameters

The values for these required parameters are set when you create the Runtime Fabric instance in
Runtime Manager. If you’re not using a local registry, use the default values for the registry URL
and pull secret.

<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><p>US rtf-runtime-registry.kprod.msap.io</p><p>EU rtf-runtime-registry.kprod-eu.msap.io</p></td></tr><tr><td><p><code>pullSecretName</code></p></td><td><p>Registry pull secret</p></td><td><p>rtf-pull-secret</p></td></tr><tr><td><p><code>muleLicense</code></p></td><td><p>Mule license for applications</p></td><td><p>Mule license key (must be Base64-encoded)</p></td></tr></tbody></table>

## Values.yaml Optional Parameters

Set these optional parameters as needed:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Key</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><p><code>authorizedNamespaces</code></p></td><td><p>Enables shared tenancy</p></td><td><p>authorizedNamespaces=true</p></td></tr><tr><td><p><code>crds.install</code></p></td><td><p>Enables installation of Crds and PriorityClass</p></td><td><p>install=true</p></td></tr><tr><td><p><code>proxy.http.proxy</code><br><code>proxy.http.no_proxy</code> `</p></td><td><p>Proxy and no_proxy values</p></td><td><p>- http://&lt;user&gt;:&lt;pass&gt;@&lt;10.0.0.1&gt;:&lt;8080&gt;<br>- &lt;1.1.1.1:8888,2.2.2.2:9999&gt;</p></td></tr><tr><td><p><code>proxy.monitoring.proxy</code></p></td><td><p>Monitoring proxy values</p></td><td><p>socks5://&lt;user&gt;:&lt;pass&gt;@&lt;10.0.0.2&gt;:&lt;8080&gt;</p></td></tr><tr><td><p><code>global.containerLogPaths</code></p></td><td><p>Filebeat read path</p></td><td><p>- /var/lib/docker/<br>- /var/log/containers<br>- /var/log/pods</p></td></tr></tbody></table>

> [!NOTE] For the first agent being installed on the cluster, set the value for `crds.install` to
> `true`.  
> Set `crds.install` to `false` for all the subsequent agent installations on the same cluster.

## Values.yaml Reference

The following is an example of the `values.yaml` file:

activationData: <activation\_data> proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy:
custom\_log4j\_enabled: true muleLicense: <mule\_license\_key> global: crds: install: true
authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName:
rtf-pull-secret containerLogPaths:

- /var/lib/docker/containers
- /var/log/containers
- /var/log/pods

## Deploy Mule Applications

1.  To deploy Mule applications, create an `app-namespace` for each of installed agent:

    apiVersion: v1 kind: Namespace metadata: name: <app-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.  Create the ingress in the new `<rtf_namespace>`:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace:
<rtf\_namespace> annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/rewrite-target:
/$2
spec:
  ingressClassName: rtf-nginx
  rules:
    - host: "testrtf.com"
      http:
        paths:
          - pathType: Prefix
            path: "/app-name(/|$)(.\*)"
backend: service: name: service port: name: service-port

Use a different host name per `<rtf_namespace>`. If multiple ingresses define different paths for
the same host, the ingress controller merges the definitions. As a result, Mule applications with
the same name are not accessible, which causes a k8s issue, not a Runtime Fabric issue.

## (Optional) Configure Authorized Namespaces

You can optionally configure authorized namespaces, which enables you to deploy Runtime Fabric
alongside other services in a Kubernetes cluster.

You must create the `authorized-namespaces` ConfigMap file before installing Runtime Fabric for the
Runtime Fabric namespace. Additionally, you must name the `ConfigMap`, `authorized-namespaces`. The
following example shows a `ConfigMap` file:

apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: <rtf\_namespace>
data: APPLICATION\_NAMESPACE\_1: "<app\_namespace\_1>" APPLICATION\_NAMESPACE\_2:
"<app\_namespace\_1>

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: The following example shows a ClusterRole role:

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"\]

### Configure Additional Namespaces

To configure an additional namespace for application deployments and then add the necessary labels
to the namespace, follow these steps:

1.  Create a YAML file with these contents:

    apiVersion: v1 kind: Namespace metadata: name: <app-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 previously created file:

    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` by applying this configuration in your additional namespace:

    kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: <rb\_name> namespace:
    <app\_namespace> subjects:
    - kind: ServiceAccount name: rtf-agent namespace: <rtf\_namespace> roleRef: kind: ClusterRole
      name: rtf:agent-<rtf\_namespace> apiGroup: rbac.authorization.k8s.io

## See Also

[Installing Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/2.11/install-index)