Installing Multiple Instances of Runtime Fabric on a Single Cluster | MuleSoft Documentation
# Installing Multiple Instances of Runtime Fabric on a Single Cluster
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.


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 for details.
  6. Download and configure the `values.yaml` file from the Anypoint Platform UI.
  7. Set the 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.
Key | Value | Example  
---|---|---  
`activationData` | Activation Data | YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==  
`rtfRegistry` | Registry URL | US rtf-runtime-registry.kprod.msap.io EU rtf-runtime-registry.kprod-eu.msap.io  
`pullSecretName` | Registry pull secret | rtf-pull-secret  
`muleLicense` | Mule license for applications | Mule license key (must be Base64-encoded)  
## Values.yaml Optional Parameters
Set the following optional parameters as needed:
Key | Description | Example  
---|---|---  
`authorizedNamespaces` | Enables shared tenancy | authorizedNamespaces=true  
`crds.install` | Enables installation of Crds and PriorityClass | install=true  
`proxy.http.proxy` `proxy.http.no_proxy` ` | Proxy and no_proxy values | - http://<user>:<pass>@<10.0.0.1>:<8080> - <1.1.1.1:8888,2.2.2.2:9999>  
`proxy.monitoring.proxy` | Monitoring proxy values | socks5://<user>:<pass>@<10.0.0.2>:<8080>  
`global.containerLogPaths` | Filebeat read path | - /var/lib/docker/ - /var/log/containers - /var/log/pods  
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 the following 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 the following 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