Contact Us 1-800-596-4880
  1. Homepage
  2. Runtime Fabric (1.12)

  3. On Self-Managed Kubernetes

Anypoint Runtime Fabric on Self-Managed Kubernetes

Anypoint Runtime Fabric on Self-Managed Kubernetes enables you to deploy Mule applications and API proxies to a Kubernetes cluster that you create, configure, and manage. 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.

Core Components of Anypoint Runtime Fabric on Self-Managed Kubernetes

Anypoint Runtime Fabric on Self-Managed Kubernetes and its underlying components run as Kubernetes deployment objects in EKS, AKS, or GKE environments. You manage the objects via Anypoint Platform.

Linux-based operating systems are required for all nodes that run Runtime Fabric components on self-managed Kubernetes clusters.

The Runtime Fabric Agent

The Runtime Fabric agent is deployed as a pod in the cluster and communicates with the control plane via an mTLS outbound connection established at startup.

The agent is event-driven. When an application state change generates a Kubernetes event, the agent sends metadata describing the current state of the application to the control plane. Kubernetes events include application pod starts, updates, or restarts.

The agent also listens for incoming requests from the control plane. When the agent receives a message from the control plane, the agent makes changes to the Kubernetes resources specified in the message. Such changes include creating a new application, updating an existing application, or deleting an application.

Additional Cluster Components

The following Runtime Fabric components also run inside the Kubernetes cluster:

  • Mule cluster IP service: Provides an API that Mule applications use to discover their peers inside the cluster

  • Resource cache: Provides a cluster-local cache of application dependencies

  • Persistence gateway: Provides a persistent ObjectStore interface to Mule applications

About Component Installations and Upgrades

When you install Anypoint Runtime Fabric on Self-Managed Kubernetes on your 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 credentials to establish an mTLS connection to Anypoint Platform. The utility then invokes Helm to perform the installation.

You trigger upgrades to the Anypoint Runtime Fabric on Self-Managed Kubernetes components in your cluster from the Anypoint Platform control plane, specifically from Runtime Manager. When you trigger an upgrade, an upgrade message is processed inside the target cluster, and rtfctl invokes Helm to upgrade the components' software versions. If you encounter a problem during an upgrade, you 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.

How Application Deployments Work in Anypoint Runtime Fabric on Self-Managed Kubernetes

When you deploy an application in Anypoint Runtime Fabric on Self-Managed Kubernetes, the following occurs:

  1. You use Runtime Manager to trigger the application deployment.

  2. The Runtime Fabric agent in the target cluster receives a request to deploy the application.

  3. Runtime Fabric assigns the application to an existing namespace or creates a new namespace if necessary.

  4. Runtime Fabric generates the appropriate Kubernetes resources, including a deployment, ConfigMap, secrets, services, and ingress.

  5. If the Kubernetes deployment resource includes an init container, it fetches dependencies from the Runtime Fabric resource cache.

  6. If the resource cache doesn’t contain required dependencies, Runtime Fabric fetches them from the control plane and adds them to the resource cache.

Application deployment workflow for Anypoint Runtime Fabric on Self-Managed Kubernetes

Assigning Namespaces in Anypoint Runtime Fabric on Self-Managed Kubernetes

Each application is deployed into a Kubernetes namespace based on the application’s environment.

  1. Runtime Fabric searches for a namespace with the label rtf.mulesoft.com/envId=<ANYPOINT_ENVIRONMENT_ID>.

  2. If Runtime Fabric can’t find that label, it searches for a namespace with the name <ANYPOINT_ENVIRONMENT_ID>.

  3. If Runtime Fabric can’t find that namespace, it creates a new namespace called <ANYPOINT_ENVIRONMENT_ID>.

Application namespace assignment flowchart

Monitoring Application Deployments

The Runtime Fabric agent monitors Kubernetes Deployments labelled with rtf.mulesoft.com/id. When Kubernetes updates the state of the deployment, the agent sends that update to the control plane. See Logs and Monitoring for addtional information.

Anypoint Runtime Fabric on Self-Managed Kubernetes as a Shared Responsibility

The successful operation of Anypoint Runtime Fabric on Self-Managed Kubernetes is a shared responsibility. It is critical to understand which areas you provide and manage and which areas MuleSoft provides.

The following image illustrates different MuleSoft and customer responsibilities for Anypoint Runtime Fabric on Self-Managed Kubernetes instances:

Anypoint Runtime Fabric on Self-Managed Kubernetes Shared Responsibilities Diagram

  • MuleSoft provides

    MuleSoft provides the Runtime Fabric agent, Mule runtime engine (Mule), and other dependencies used to deploy Mule applications. The Runtime Fabric agent deploys and manages Mule applications by generating and updating Kubernetes resources such as deployments, pods, Replicasets, and ingress resources.

  • Customer responsibility

    Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for Anypoint Runtime Fabric on Self-Managed Kubernetes. Additional configuration used to set up or enable capabilities on the Kubernetes cluster, such as those listed below, are also the customer’s responsibility to manage:

    • Ingress controller and external load balancing

    • Customizations to Ingress resources

    • Log forwarding

    • Monitoring

    • Network ports, NAT gateways, and proxies

    • Container runtime and networking

    • Provisioning and management of the Kubernetes environment. This requires assistance from the following teams in your organization:

      • IT team to provision and manage the infrastructure

      • Network team to specify allowed ports and configure proxy settings

      • Security team to verify compliance and obtain security certificates

Requirements for Runtime Fabric on Self-Managed Kubernetes

The following descriptions provide you with the general requirements for running Anypoint Runtime Fabric on Self-Managed Kubernetes.

Kubernetes Support

Runtime Fabric on Self-Managed Kubernetes requires a dedicated cluster that is provisioned and operational. Verify if your environment is correctly configured using the rtfctl command-line utility. See Install Runtime Fabric on Self-Managed Kubernetes.

Runtime Fabric on Self-Managed Kubernetes supports the following Kubernetes versions:

  • 1.18.x

  • 1.19.x

  • 1.20.10 or later patch versions on 1.20.x

  • 1.21.3 or later patch versions on 1.21.x

Supported Architectures

Anypoint Runtime Fabric on Self-Managed Kubernetes requires worker nodes that use the x86/x64 architecture. ARM-based architectures are not supported.

Operating Systems

Anypoint Runtime Fabric on Self-Managed Kubernetes supports any Linux-based operating system supported by Amazon EKS, AKS, or GKE.

Nodes and Resources

In general, you should follow the best practices provided by your Kubernetes vendor to ensure availability and simplify the administration of your infrastructure.

Follow best practices by installing Runtime Fabric on Self-Managed Kubernetes in an environment with a minimum of two nodes each having the following resources:

  • Minimum of two CPU cores

  • At least 15 GiB of RAM

  • At least 250 GiB of available disk space

Adjust the number of nodes and amount of resources allocated according to the amount and type of workload you run on each Anypoint Runtime Fabric on Self-Managed Kubernetes instance.

Anypoint Platform Roles and Permissions

To successfully use Anypoint Runtime Fabric on Self-Managed Kubernetes, your Anypoint Platform account must have the following permissions enabled:

  • To manage permissions for Anypoint Platform users, you must have the ability to use Anypoint Access Management.

  • To deploy and manage applications, you must have the ability to use Anypoint Runtime Manager. To deploy applications, you must also have the Exchange Contributors permission enabled for your Anypoint Platform account.

  • To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission for the corresponding environments.

  • To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level.

Network Configuration

Anypoint Runtime Fabric on Self-Managed Kubernetes requires an IT administrator to configure network ports, hostnames, and certificates to function correctly. See Install Runtime Fabric on Self-Managed Kubernetes.

Anypoint Platform Roles and Permissions

To succesfully use Runtime Fabric, your Anypoint Platform account must have the following permissions enabled:

  • To manage permissions for Anypoint Platform users, you must have the ability to use Anypoint Access Management.

  • To deploy and manage applications, you must have the ability to use Anypoint Runtime Manager. To deploy applications, you must also have the Exchange Contributors permission enabled for your Anypoint Platform account.

  • To use Runtime Fabric, you must have the Organization Administrators permission or the Manage Runtime Fabrics permission on the corresponding environments.

  • To delete Runtime Fabric instances, administrators need the Manage Runtime Fabrics permission at the organization level.

Ingress Controller

Runtime Fabric on Self-Managed Kubernetes supports any ingress controller that is compatible with your Kubernetes environment and supports a deployment model where a separate ingress resource is created per application deployment. In general, most off-the-shelf ingress controllers support this model.

For GKE customers, the ingress controller included with GKE provisions a separate HTTP load balancer per application by default. Before using the ingress controller provided by GKE, learn more about its behavior, exploring workarounds, or using another ingress controller if this behavior is undesirable. See KB article for more details.

Logs

Applications deployed on Runtime Fabric on Self-Managed Kubernetes direct logs to stdout. The container runtime collects these logs and writes them to a file. The storage location of this file depends on your container runtime and configuration. Refer to the documentation for your Kubernetes environment for details.

External Log Forwarding

Anypoint Runtime Fabric on Self-Managed Kubernetes does not include external log forwarding. You are responsible for installing, configuring, and managing an external log forwarder. You can use any external log forwarding agent that is compatible with your Kubernetes environment running on Amazon EKS, AKS, or GKE. Common log forwarding agents include:

  • Splunk Connect for Kubernetes

  • Fluentbit

For Titanium customers, Anypoint Runtime Fabric on Self-Managed Kubernetes supports logging using Anypoint Monitoring. See Logs in Anypoint Monitoring for more information.

Monitoring

Anypoint Monitoring provides metrics for applications and API gateways deployed to Runtime Fabric.

To collect metrics, Anypoint Monitoring sidecars run in all applications deployed to Runtime Fabric. See Monitor Applications Deployed to Runtime Fabric for details, including how to enable or disable monitoring.

Runtime Fabric does not provide support for integrating third-party monitoring solutions.

See Also