Migrating Runtime Fabric: VMs/Bare Metal to self-managed Kubernetes

This blog serves as a guide to help you better understand the requirements, considerations, and processes that go into migrating from Runtime Fabric on VMs/Bare Metal to Runtime Fabric running on self-managed Kubernetes. These processes may need to be adjusted based on the infrastructure environment and goals for availability during your migration.

This guide describes a procedure to:

1. Set up a new Runtime Fabric with the same settings and custom configurations to match the existing instance.
2. Deploy applications running on the existing Runtime Fabric onto the new environment.
3. Use a TCP load balancer to direct incoming requests from the existing Runtime Fabric to the new environment.
4. Discard the existing Runtime Fabric environment after sufficient time has passed with the new hosting applications successfully.

Differences in capabilities

Review the differences in capabilities between Runtime Fabric on self-managed Kubernetes compared with Runtime Fabric on VM/Bare Metal. If there are capabilities not supported which are required by your team, you should re-evaluate your migration to Runtime Fabric on self-managed Kubernetes.

In addition, the following application deployment settings are not available in Runtime Manager when deploying on to Runtime Fabric on self-managed Kubernetes:

• Under ingress:
  • Last-mile security: Work with your Kubernetes operator to configure with the ingress controller.
  • Forward SSL session: Work with your Kubernetes operator to configure with the ingress controller.
• Under logs:
  • Forward application logs to an external service: Work with your Kubernetes operator to configure external log forwarding.

Personas

Runtime Fabric on self-managed Kubernetes requires a minimum of the following personas which allow you to manage Runtime Fabric cluster:

• Project architect or MuleSoft administrator
• K8s operator or IT specialist with proficiency in managing Kubernetes
  • If running on a cloud-managed Kubernetes service, this persona is expected to have proficiency in managing their cloud infrastructure.
• Network administrator to make adjustments in your environment’s allow list

Requirements

To begin the installation process for your Runtime Fabric on self-managed Kubernetes, verify that:

• An EKS or AKS Kubernetes environment that’s dedicated for running Mules.
• TLS certificates used to configure the internal load balancer in Runtime Fabric on VMs/bare metal.
• Sufficient Mule licensing cores to run Mule deployments across both Runtime Fabrics while migrating.

Procedure

Some of the prerequisites that this procedure of installing the Runtime Fabric on Self-Managed Kubernetes assumes are the following:

• You’re running a production configuration of Runtime Fabric on VMs/bare metal.
• The controller nodes for your Runtime Fabric are fronted by a TCP load balancer.
• Your Runtime Fabric is reporting healthy when running rtfctl status.
• Your Runtime Fabric is showing as active in Anypoint Runtime Manager.
• You have one or more applications running on Runtime Fabric.
• Minimal downtime for running applications is desired during the migration.

Set up the Kubernetes environment

These steps will be performed by the K8s operator and network administrator:

1. Ask your K8s operator to provision a new EKS or AKS environment.
   1. Provide guidance on the amount of CPU cores and memory to have available for each worker node. These values will serve as the absolute maximum amount of cores and memory you’ll be able to allocate for an individual replica.
   2. Provide guidance on the amount of cores you are licensed to operate on this environment. This will help the K8s operator adjust the maximum number of worker nodes the K8s environment can scale to.
   3. While not required, we recommend having at least two worker nodes available at all times to reduce the time your Kubernetes environment has to recover from node-based failures.
2. Ask your K8s operator to configure support for ingress on the EKS or AKS environment. Ensure your K8s operator has the following:
   1. Access to the TLS certificates used to configure the internal load balancer on Runtime Fabric on VMs/bare metal.
   2. The domain schemes your current applications are using, including specifics regarding use of subdomain or path-based routing.
   3. The amount of CPU and memory the internal load balancer is configured for with the existing Runtime Fabric.
3. Ask your K8s operator to set up log forwarding on your EKS or AKS environment on your external log service.
4. If needed, ask your network administrator to allow the full list of ports and hostnames on the environment where your Runtime Fabric on self-managed Kubernetes will run. Below are the additive hostnames introduced with this release:

1. If needed, verify with your K8s operator that any HTTP or SOCKS5 proxies which were used with your existing Runtime Fabric have been properly configured with the Kubernetes environment.

If your environment relies on outbound proxies for access to the hostnames, it is important that the Kubernetes environment is aware it must use those proxies to pull down required Docker images from MuleSoft’s container registry.

Install Runtime Fabric on the Kubernetes environment

These steps will be performed by the K8s operator and MuleSoft administrator:

1. In Anypoint Platform, navigate to Runtime Manager > Runtime Fabrics and create a new Runtime Fabric.
   • Name your Runtime Fabric
   • Select the EKS or AKS option
2. After submitting, you’ll see the link to the installation instructions and an activation data string. Send both to your K8s operator, along with your Mule license key and the proxies mentioned above (if applicable), and ask them to follow the instructions in the documentation.
   • Your K8s operator should have installed Runtime Fabric on the Kubernetes environment and injected the Mule license key. To validate, you should see your Runtime Fabric status in Anypoint Runtime Manager report as active.
   • Confirm with your K8s operator the endpoint the new Runtime Fabric is set up to use. You’ll need this to send requests to Mules deployed on the new Runtime Fabric.
   • You can use the License Key Validator to check if the Mule license key is valid.
3. In Anypoint Runtime Manager:
   • Associate the new Runtime Fabric with Anypoint environments and business groups to match your existing Runtime Fabric.
   • Add the domains your K8s operator configured with inbound requests to the new Runtime Fabric in the inbound traffic section of Runtime Fabric in Runtime Manager.
     • This step is only required if you require subdomain routing for your applications.
     • If this is unspecified, you won’t be able to select a domain during application deployment.
4. Gather any secure properties inserted into your Runtime Fabric on VMs/bare metal and ask your K8s operator to insert those secrets into the new Runtime Fabric, using the commands offered via rtfctl. Documentation can be found here.

Deploy applications and API gateways on Runtime Fabric

Existing application with their API Manager policies needs to be deployed to new Runtime Fabric. The steps below can be performed by the project architect or a Mule application developer:

1. Deploy a test application on the new Runtime Fabric. The below example illustrates this procedure from the Runtime Manager UI, but these steps can be performed via Platform APIs or Maven.
   • Create a new application deployment with the same name as the existing application.
   • Under the deployment target, select the new Runtime Fabric.
     • If you do not see the new Runtime Fabric, verify the Runtime Fabric is associated with the correct environment and business groups.
   • Import the application artifact from Exchange, with the version that matches the existing deployment running on the existing Runtime Fabric.
   • Set the version of Mule runtime, CPU values, memory value, replica count, and other settings to match the existing deployment on the existing Runtime Fabric. Go through each tab to set the values accordingly.
   • Deploy the application on the new Runtime Fabric, and confirm the deployment is successful.
2. If your Mule application accepts inbound requests, use the endpoint provided by your K8s operator to verify requests can be routed to your deployed application.
   • If you suspect inbound requests are not reaching your Mule application, work with your K8s operator to troubleshoot configuration issues with the underlying network, ingress controller, or ingress override template.
   • If running on Kubernetes v1.18 or above, verify your K8s operator has configured the ingress override template to specify the ingress class. Reference the documentation provided by the ingress controller configured on the Kubernetes environment for more information.
3. Repeat the above steps in this subsection to deploy all applications onto the new Runtime Fabric.
4. When deploying via platform APIs or the Mule Maven Plugin — as commonly used for CI pipelines — ensure the following capabilities are not specified, as they are not supported on Runtime Fabric on self-managed Kubernetes:
   • Mule Application deployment settings Parameters such as lastMileSecurity

Add new Runtime Fabric nodes to TCP load balancer

Self-managed Kubernetes nodes needs to be added to TCP Load Balancer so that it can cater to live traffic. The steps below can be performed by the K8s operator, with assistance from the network administrator:

1. Ask your K8s operator to set up the TCP load balancer fronting the existing Runtime Fabric to add the nodes with the new Runtime Fabric.
   • The nodes required to be added to the TCP load balancer server pool are those which are running the ingress controller.
2. At this point, applications running on the existing and new Runtime Fabric should be serving inbound requests. This can be validated by viewing the metrics from the applications running on the new Runtime Fabric using Anypoint Monitoring.

Stop requests from entering the existing Runtime Fabric

After self-managed Kubernetes Runtime Fabric is added to TCP Load Balancer, incoming requests to existing Runtime Fabric should be stopped. The steps below can be performed by the K8s operator, with assistance from the network administrator.

1. When ready, ask your K8s operator to remove the existing Runtime Fabric controller nodes from the TCP load balancer server pool.
2. Verify the applications running on the existing Runtime Fabric are no longer serving requests via examining their metrics using Anypoint Monitoring.

Discard the existing Runtime Fabric

Once all the MuleSoft application are migrated to self-managed Kubernetes, existing Runtime Fabric cluster can be deleted. The steps below require the IT administrator and project architect:

1. After validating the applications deployed on the new Runtime Fabric are behaving as expected, un-deploy the applications running on the existing Runtime Fabric from Anypoint Runtime Manager.
2. Delete the existing Runtime Fabric from Anypoint Runtime Manager by navigating to Runtime Manager > Runtime Fabrics > Selecting the existing Runtime Fabric > Selecting “Delete Runtime Fabric,” and confirming the selection.
3. Ask your IT administrator to discard the infrastructure running the existing Runtime Fabric.

Summary

With Runtime Fabric on self-managed Kubernetes, customers can bring their infrastructure and their own Kubernetes (k8s), as long as that k8s service is AKS or EKS or (Google Kubernetes Engine GKE coming soon). This allows customers greater control, transparency, and flexibility by using Amazon’s k8s service or Azure’s k8s service. EKS/AKS are highly available and managed by cloud providers freeing up developer time to focus on integration/API development. The Runtime Fabric appliance, therefore, gets replaced with the customer’s own AKS/EKS.

To learn more about Runtime Fabric, take our Anypoint Platform Operations: Runtime Fabric course. If you would need help with the migration implementation, contact MuleSoft Professional Services or a MuleSoft Partner.