Anypoint Runtime Fabric and Different Deployment Options
Written by Ali Akthar
Technical Account ManagerAnypoint Runtime Fabric on Self-Managed Kubernetes
Anypoint Runtime Fabric on Self-Managed Kubernetes lets you deploy Mule applications and API proxies to a Kubernetes cluster that are created, configured, and managed by you. Anypoint Runtime Fabric on Self-Managed Kubernetes runs as a service in existing Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) environments.
How Does that Work?
Anypoint Runtime Fabric works as a Kubernetes deployment object in AKS, EKS, or GKE environments. All the things are being managed via the Anypoint Platform. Linux-based operating systems are required for all nodes that run Runtime Fabric components on self-managed Kubernetes clusters.
Deployment of Anypoint Runtime Fabric Agent
The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via a mutual TLS outbound connection established at startup. The Runtime Fabric agent is event driven. When an application state change generates a Kubernetes event, the RTF sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts.
The Runtime Fabric agent also listens for incoming requests from the control plane. When the Fabric agent receives a message from the control plane, the Fabric agent changes the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application.
Installation & Upgrade
The Anypoint Runtime Fabric installed on Self-Managed Kubernetes on the provided Kubernetes cluster, the command-line utility (rtfctl) swaps an activation data token for a set of activation properties. Properties include credentials to access the Runtime Fabric Docker registry and establish a mutual TLS connection to the Anypoint Platform. The utility then invokes Helm to perform the installation.
This trigger upgrade to the Anypoint Runtime Fabric on Self-Managed Kubernetes components in the provided cluster from the Anypoint Platform control plane, specifically from Runtime Manager. When the upgrade is initiated, an upgrade message is processed inside the target cluster, and rtfctl invokes Helm to upgrade the components' software versions. If someone encounters a problem during an upgrade, they can use rtfctl to invoke a Helm rollback and restore the cluster to a stable state. A rollback creates a report in the control plane.
What is Helm?
Helm is a Kubernetes deployment tool for automating the creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters. Kubernetes is a powerful container-orchestration system for application deployment
Application Deployment in Anypoint Runtime Fabric
During the deployment of application in Anypoint Runtime Fabric on Self-Managed Kubernetes, the following occurs:
- Runtime Manager is used to trigger the application deployment.
- The Runtime Fabric agent receives the target cluster request to deploy the application.
- Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary.
- Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress.
- If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache.
- If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache.
Assigning Namespaces in RTF
Each application is deployed into a Kubernetes namespace based on the application’s environment.
- Runtime Fabric searches for a namespace with the label rtf.mulesoft.com/envId=< ANYPOINT_ENVIRONMENT_ID >.
- If Runtime Fabric can’t find that label, it searches for a namespace with the name < ANYPOINT_ENVIRONMENT_ID >.
- If Runtime Fabric can’t find that namespace, it creates a new namespace called < ANYPOINT_ENVIRONMENT_ID >.
Monitoring Application Deployments
There are logs available for monitoring of application deployment. Runtime Fabric agent monitors Kubernetes deployment rtf.mulesoft.com/id. When Kubernetes update the state of deployment, the RFT agent sends the update to the control plane.
Runtime Fabric on VMs / Bare Metal
Anypoint Runtime Fabric on VMs / Bare Metal Architecture is a set of VMs that form a cluster. Each VM serves as either a controller or as a worker node.
- Controller: A VM committed to operating Runtime Fabric, which includes orchestration services, a distributed database, load balancing, and services for managing the cluster from Anypoint Platform.
- Worker: A VM geared to Mule apps and API gateways. Workers are used to run Mule apps and API proxies.
The worker nodes can be scaled based on the number of Mule applications due to the separation of duties. It also allows the controller nodes to be scaled based on the number of installations, changes in application state, and inbound traffic. MuleSoft suggests over-provisioning the amount of worker nodes to guarantee resources are available to re-schedule and re-deploy applications in the case of a hardware breakdown.
To avoid a single point of failure in the system, the services that run Runtime Fabric are distributed throughout the controller nodes by default. Anypoint Runtime Fabric on VMs / Bare Metal Architecture uses a set of technologies, including Docker and Kubernetes, which are tuned to operate well with Mule runtimes. Knowledge of these technologies is not required to deploy or manage Mules on Runtime Fabric. Managing Runtime Fabric requires the operational and infrastructure-level experience needed to support any system at scale.
Development Configurations
The development configuration is solely meant to be used for testing. At least one controller & two worker nodes are required. The internal load balancer & agents needed to connect to Anypoint Platform are executed on the controller node. The agent's communication with the Anypoint Platform is always outbound. Workers can run many copies of the same program.
Production Configuration
Only controllers run the internal load balancer and agents used to connect to Anypoint Platform. Agents can run on any controller. Agent communication is always outbound.
The minimum requirements are 3 controller and 3 worker nodes. 3 controllers enable a fault-tolerance of losing 1 controller. To improve fault-tolerance to lose 2 controllers, a total of 5 controllers should be configured. Mule applications run on workers. Multiple replicas of applications can run across workers.
Network Architecture
This diagram shows the TCP load balancer used to load balance requests across the internal load balancers running on the controllers. It also shows the internal load balancer that distributes requests to each replica of Mule applications running on the workers. To Enable an internal load balancer, the following modes are supported:
- Shared Mode: The default setting if no dedicated internal load balancer node is added in Runtime Fabric on VMs / Bare Metal. In this mode, the internal load balancer runs on all controller nodes with the specified amount of CPU and memory.
- Dedicated Mode: Enabled only if one or more dedicated internal load balancer nodes is available in Runtime Fabric on VMs / Bare Metal. Because dedicated internal load balancer nodes use all available resources for running the internal load balancer, you cannot specify the amount of CPU cores and memory.
What MuleSoft Deployment Should You Use?
Mule On-Premise is well-suited for highly regulated enterprises, whereas CloudHub is extensively utilized in environments where data is moved back and forth for innumerable transactions. The disadvantages include the inability to access local file systems, transfer files between apps, and some restrictions when using object stores (in-memory DB).
Using out-of-the-box components, Anypoint Runtime Fabric enables teams to quickly develop features such as trusted application separation, scaling, and application deployments with zero downtime. In summary, Anypoint Runtime Fabric helps companies quickly and efficiently satisfy changing business requirements by bridging the gap between numerous clouds and on-premise resources.
Read along this whitepaper to know more about the Key Steps to Cultivating an API Ecosystem with MuleSoft.
Conclusion
Would you like assistance from MuleSoft experts in choosing the deployment options? Get started by reaching out to our MuleSoft Professionals at Royal Cyber for deeper insights into how organizations worldwide are driving their digital transformation through AnyPoint Runtime Fabric. For more information, you can email us at info@royalcyber.com or visit www.royalcyber.com.
