Anypoint Runtime Fabric on Self-Managed Kubernetes

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.

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

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.

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

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.

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.

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:

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.

See the release notes for your major or minor version of Runtime Fabric for a list of supported Kubernetes versions.

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

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

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:

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.

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

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

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.

Anypoint Monitoring provides access to log data for applications deployed to Runtime Fabric. To access logs with Anypoint Monitoring, you need the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform.

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.

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:

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

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.