How does the shared deployment process work in Runtime Fabric (RTF) and CloudHub 2.0?

Both Runtime Fabric (RTF) and CloudHub 2.0 (CH2) are containerized Mule runtimes built upon Kubernetes. They share an identical core deployment sequence and pod layout:

Deployment Sequence

When deploying via Anypoint Runtime Manager, the control plane orchestrates artifact distribution through Anypoint Exchange before directing the local agent to create cluster deployment resources:

1. The deployer uploads the application package (.jar) to Anypoint Runtime Manager.
2. The artifact is stored in the Anypoint Exchange / artifact repository.
3. Runtime Manager alerts the RTF or CH2 control agent in the target environment.
4. The agent creates the Kubernetes Deployment and ReplicaSet definitions.
5. Ingress controllers update routing while Kubernetes pulls the container image to launch initial pods.

Pod Architecture

Within the Kubernetes cluster, each application replica runs inside a dedicated Pod containing the Mule runtime container and companion sidecars:

• Mule App Container: Runs the Mule runtime JVM and application flows.
• Init / Log Sidecars: Handle configuration injection and stream logs to Anypoint Monitoring or external SIEMs.
• Resource Limits: CPU and memory quotas are strictly enforced per pod according to allocated vCore sizing.

Related Links & Documentation

• CloudHub 2.0 Architecture Overview
• Runtime Fabric Architecture Guide