Runtime Fabric on Self-Managed Kubernetes
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. Runtime Fabric runs as a service on an existing Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE) environment.
Architecture
Runtime Fabric on Self-Managed Kubernetes and its related components run as services on your Amazon EKS, AKS, or GKE environment. The following diagram shows different layers of the architecture.
MuleSoft is responsible for providing support for Runtime Fabric services, the Mule Runtime server, and Mule applications. You are responsible for creating, configuring and managing the Amazon EKS, AKS, or GKE environment.
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 must manage and which areas are managed by MuleSoft.
The following image illustrates different MuleSoft and customer responsibilities for on-premises Runtime Fabric instances:
-
MuleSoft responsibility:
MuleSoft is responsible for the Runtime Fabric agent, Mule runtime engine, 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 default ingress resources.
-
Customer responsibility:
Customers are responsible for provisioning, configuring, and managing the Kubernetes cluster used for 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
-
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
The sections below describe the requirements for running Runtime Fabric on Self-Managed Kubernetes.
Network Configuration
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.
Kubernetes
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.17.x
-
1.18.x
-
1.19.x
-
1.20.10 or later patch versions on 1.20.x
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 amout of resources allocated according to the amount and type of workload you run on each Runtime Fabric.
Supported Architectures
Runtime Fabric on Self-Managed Kubernetes requires worker nodes which use the x86/x64 architecture. ARM-base architectures are not supported.
Operating Systems
Runtime Fabric on Self-Managed Kubernetes supports any Linux-based operating system supported by Amazon EKS, AKS, or GKE.
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
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, 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.