Runtime Fabric Manager on Self Managed Kubernetes differs from Runtime Fabric Manager on bare metals/VMs in several ways: On Self Managed Kubernetes, the Kubernetes control plane is managed by the cloud provider, whereas on bare metals/VMs the user manages the control plane. Self Managed Kubernetes provides benefits like auto-scaling and monitoring that are handled by the cloud provider. The user also has flexibility to choose their own ingress load balancer and operating system when using Self Managed Kubernetes. However, there are some limitations when using Self Managed Kubernetes, such as a lower maximum number of nodes and replicas per application.

1. Runtime Fabric Manager on Self Managed Kubernetes and how
it is differed from Runtime Fabric Manager on Bare Metals/VMs
Surat MuleSoft Meetup Group
June 4, 2022
11:00 IST (GTM+05:30)

2. Safe Harbour Statement
● Both the speaker and the host are organizing this meet-up in individual capacity only. We are
not representing our companies here.
● This presentation is strictly for learning purposes only. Organizer/Presenter do not hold any
responsibility that same solution will work for your business requirements.
● This presentation is not meant for any promotional activities.
2

3. A recording of this meetup will be uploaded to events page within 24 hours.
Questions can be submitted/asked at any time in the Chat/Questions & AnswersTab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of theday.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
3

4. Organizers
4
Jitendra Bafna
Senior Solution Architect
EPAM Systems
Nitish Jain
Application Developer
Accenture

5. 5
Speaker
Jitendra Bafna
Senior Solution Architect
EPAM Systems

6. Agenda
● Introduction
● What is Elastic Kubernetes Service and its Architecture?
● What is Runtime Fabric Manager and its Architecture?
● Benefits of EKS/RTF?
● Ingress Controller, Last Mile Security, Persistence Gateway
● Anypoint Runtime Fabric on Self-Managed Kubernetes (EKS) as a Shared Responsibility
● CPU Bursting

7. A container is a standard unit of software that
packages up code and all its dependencies so the
application runs quickly and reliably from one
computing environment to another. It packages the
code and its dependencies together
What is Containerization ?
7
Docker is an open platform for developing, shipping, and running
applications. Docker enables you to separate your applications from
your infrastructure so you can deliver software quickly. With Docker,
you can manage your infrastructure in the same ways you manage
your applications.

8. MuleSoft Deployment Model

9. What is EKS?
EKS is a fully managed AWS service that makes you run Kubernetes
on AWS without requiring the user to maintain their own Kubernetes
in Control plane. It is an AWS service to run, manage, scale or deploy
the containerized application in the Kubernetes.
In EKS architecture, the Kubernetes control plane is managed by
EKS that is running in EKS managed VPC. EKS automatically
manages the scalability and durability of the Kubernetes control
plane nodes, and it automatically replaces unhealthy nodes.

10. EKS Architecture
Destination Target
VPC CIDR local
0.0.0.0/0 firewall-az-1
Private Subnet Route Table
Destination Target
VPC CIDR Local
0.0.0.0/0 NAT Gateway
Firewall Subnet Route Table
Destination Target
VPC CIDR Local
0.0.0.0/0 igw
Public Subnet Route Table
Public Subnet
Firewall Subnet
Private Subnet
Destination Target
VPC CIDR local
0.0.0.0/0 firewall-az-2
Private Subnet Route Table
Destination Target
VPC CIDR local
0.0.0.0/0 NAT Gateway
Firewall Subnet Route Table
Destination Target
VPC CIDR local
0.0.0.0/0 Igw
Public Subnet Route Table
Public Subnet
Firewall Subnet
Private Subnet
Destination Target
VPC CIDR local
0.0.0.0/0 firewall-az-3
Private Subnet Route Table
Destination Target
VPC CIDR local
0.0.0.0/0 NAT Gateway
Firewall Subnet Route Table
Destination Target
VPC CIDR Local
0.0.0.0/0 igw
Public Subnet Route Table
Public Subnet
Firewall Subnet
Private Subnet
EKS Node EKS Node EKS Node
Firewall Endpoints Firewall Endpoints Firewall Endpoints
NAT Gateway NAT Gateway NAT Gateway
Internet
Gateway
AWS EKS
Control Plane
AZ-1 AZ-2 AZ-3
AWS Managed VPC
Ingress Managed
Load Balancer
Kubectl
Client
• Private, Public and Firewall Subnet spin up across multiple AZ for High
Availability.
• Separate Route Tables for Private, Public and Firewall Subnet.
• Outbound Traffic from Private Subnet will be route through Firewall Subnet
and ensure outbound traffic to destination is allowed.
• Client can connect to application via Ingress Load Balancer.
Request from
Private Subnet
Firewall Subnet Validate
whether traffic is
allowed or not
Traffic routed to NAT
Gateway in Public
Subnet
Traffic routed outside
via Internet Gateway
Response from outside
comes to IG and routed
to NAT in Public Subnet
Response will send to
Firewall Subnet for
filtering and validation
Response will send to
Private Subnet
EKS Managed
ENI

11. What is Runtime
Fabric Manager?
• Runtime Fabric (RTF) is a container service to
deploy mule runtime on cloud (AWS / Azure) or on
a data center (on-premise).
• Anypoint Runtime Manager on Self-Managed
Kubernetes allows you to deploy the MuleSoft
application and API proxies on Kubernetes Cluster.
• There are two management options for
Anypoint Runtime Fabric:
• Runtime Fabric on Self-Managed
Kubernetes
• Runtime Fabric on VMs / Bare Metal

12. RTF on Self Managed Kubernetes RTF on Bare Metal Serve/VMs

13. RTF on Self Managed Kubernetes
RTF on Bare Metal Serve/VMs

14. Some Features – Runtime Fabric Manager on Self
Managed Kubernetes
INGRESS CONTROLLER - ANYPOINT
RUNTIME FABRIC MANAGER
ALLOWS YOU TO SPECIFY CUSTOM
INGRESS CONFIGURATION USING
AN INGRESS RESOURCE TEMPLATE.
INGRESS HAS CAPABILITIES LIKE SSL
TERMINATION OR OFFLOADING,
SSL TUNNELING, LOAD BALANCING,
ROUTING ETC. INGRESS EXPOSES
HTTP OR HTTPS ROUTES FROM
OUTSIDE THE CLUSTER TO THE
SERVICES WITHIN THE CLUSTER.
PERSISTENCE GATEWAY -
PERSISTENCE GATEWAY ALLOWS
YOU TO STORE THE APPLICATION
OBJECT STORE OR VM DATA AND
THAT CAN BE SHARED ACROSS THE
APPLICATIONS. WITH PERSISTENCE
GATEWAY, THIS DATA WILL BE NOT
LOST OR PERSISTED IN CASE
APPLICATION RESTARTS.
PERSISTENCE GATEWAY SUPPORTS
ONLY POSTGRESQL DATABASES.
LAST MILE SECURITY - LAST MILE
SECURITY ENABLES HTTPS TRAFFIC
BETWEEN INGRESS AND
APPLICATION DEPLOYED ON
WORKER NODES. RUNTIME FABRIC
MANAGER ON SELF-MANAGED
KUBERNETES DOES NOT INCLUDE
INGRESS IN PRODUCT SCOPE. IT IS
PART OF INGRESS
CONFIGURATION, AND THIS MAY
VARY AS PER INGRESS HAS BEEN
USED. APPLICATION DEPLOYED TO
EKS CLUSTER ALWAYS LISTENS ON
PORT 8081.

15. Ingress Controller
Persistence Gateway
Last Mile Security

16. Runtime Fabric Manager CPU bursting is using Kubernetes based CPU Bursting technology. With CPU
Bursting, applications running in the pod can consume sparer CPU than allocated. This event will occur
when the application is overloaded due to more requests hits and needs more CPU than actually
allocated. You need to ensure that CPU consumption is not more than what you have paid, even in case
of the CPU bursting.
When you deploy an application to Runtime Fabric Manager, you need to set Reserved CPU and CPU
Limit. This means your application will guarantee to get the Reserved CPU and in case application
requires more CPU, it can go up to CPU Limit defined and this will be only possible if that much of CPU is
free.
CPU Bursting

17. Runtime Fabric Manager -
Benefits
Reduce Infrastructure Cost - Amount of Infrastructure required for
setting up and managing the Runtime Fabric Manager is to reduce
footprint.
More visibility to operation teams for managed Kubernetes
environments and Self-Managed Kubernetes service providers like
AWS and Azure offered Auto Scaling, automatic Kubernetes upgrades
and monitoring.
Kubernetes controller is managed by Self-Managed Kubernetes
service providers like AWS and Azure.
Flexibility of choosing own ingress load balancer and preferred Linux-
based operating system in case of Self-Managed Kubernetes.

19. Implementing TLS on EKS
To enable TLS, you need certificates (private and public key) to be stored in
Kubernetes secret using the below command.
kubectl create secret tls rtf-nginx-secret --namespace rtf --key
private_key.pem --cert public_key.pem
Add the Secret name in the ingress template and apply it again on
Kubernetes. This name should match with the name of tls secret.
tls:
- hosts:
- api-test.demo.com
secretName: rtf-nginx-secret
Apply Ingress template to Kubernetes using kubectl.
kubectl apply -f ingress-tls.yaml

20. Enforce deploying replicas across nodes
If enforceDeployingReplicasAcrossNodes is
enabled, the maximum number of replicas
you can configure is equal to the number of
nodes.
With this property, you can ensure that
multiple replicas for your application are
created across multiple nodes. In case this
property is disabled, it can create multiple
replicas of the same application on the same
node and it doesn’t guarantee replicas for
the same application on different nodes. This
property can be only used if you want to
deploy multiple replicas of the same
application.

21. POD communicate with the services which are outside
EKS/RTF Cluster for which IP Whitelisting is required

22. Runtime Fabric Manager on Self
Managed Kubernetes - Limitation
Nodes The maximum number of nodes is 30.
Node types VM-based nodes are required. For example, Fargate is not supported.
Replicas per application The maximum number of replicas per application is 8.
Replicas per node The maximum number of replicas that can be deployed per node is 40.
Run no more than 20 - 25 replicas per core, up to a maximum of 40 replicas per node, to allow core sharing
across replicas when needed for bursting. This ensures the Runtime Fabric’s internal components that run on
each worker node are not overloaded by too many replicas.
Associated environments per Runtime Fabric You can associate a Runtime Fabric with up to 100 environments in any Business Group. For example, if you
associate a development and a production environment with Org A and a dev environment with Org B, that is
three environment associations.
Business groups You can create up to 50 Runtime Fabrics per org in a Business Group. Any sub org can contain up to 50 Runtime
Fabrics, in addition to any shared by another sub org. For example, if you have master Org A and its child Org B,
you can have 50 Runtime Fabrics in Org A and 50 in Org B. You can also share all 50 Runtime Fabrics from Org A
with Org B, and as a result, you will see 100 Runtime Fabrics in total in the list view of Org B.
Object store persistence To manage data persistence across Mule application replicas and restarts, Anypoint Runtime Fabric uses
Persistence Gateway. See Persistence Gateway.

23. 23
Exchange Design Center
Runtime
Manager
Access
Management
API Manager
Private Subnet
Prod Transit Gateway
Internet
Gateway
Non-Prod Transit Gateway
Customer Gateway Customer Gateway
System 1 System 2 System 3 System 4 System 5 System 1 System 2 System 3 System 4 System 5
VPN
Connection
API
EKS/RTF Data Plane (Prod) EKS/RTF Data Plane (Non-Prod)
Internet
Gateway
Runtime Fabric Manager
(Control Plane)
Firewall Subnet
NAT
Gateway
Public Subnet
Firewall
Endpoints
(Rules, Policies)
Ingress Managed Load Balancer
API
Ingress Managed Load Balancer
API
Private Subnet Firewall Subnet
Firewall
Endpoints
(Rules, Policies)
NAT
Gateway
Public Subnet
API Auto Discovery
/API Proxy
Anypoint Platform (Control Plane)
Elastic Kubernetes Service (Control Plane)
(Prod)
Elastic Kubernetes Service (Control Plane)
(Non-Prod)
EKS Managed ENI EKS Managed ENI
EKS/RTF Architecture

24. Parameters RTF on Bare Metal or Virtual Machines RTF on Self-Managed EKS
Kubernetes MuleSoft Provided Bring Your Own Kubernetes
Ingress Included Not Included
OpsCenter UI Included Not Included
External Log Forwarder Included Not Included
Kapacitor Alerts Included Not Included
Installation Options Cloud Provider Auto Scripts like AWS, Azure. Bare Metal Servers or Virtual Machines. EKS, AKS and GKE
RTF Components and Services Included Included
Docker MuleSoft Provided Customer brings own docker (Cloud Provider)
Anypoint Security Supported Not Supported
Controller Node Can Access controller Node Does not have access to controller node
Persistence Gateway Supported Supported
Last Mile Security Supported Supported
Upgrading Runtime Fabric Upgrade RTF Appliance, Components, the rtfctl command-line utility, and node
configurations
Upgrade Runtime Fabric components and the rtfctl command-line utility.
Node Types Bare Metal Servers or Virtual Machines VM-Based nodes are supported. Fargate is not supported.
Maximum Number of Controller Nodes 5 Self-Managed Controller Nodes and Auto Scalability taken care by Cloud Provider.
Maximum Number of Worker Nodes 16 30
Replicas Per Application 8 8
Replicas Per Worker Node 40 40
Associated environments per Runtime Fabric 50 100
Business groups 50 50
Object store persistence To handle data persistence across Mule application replicas and restarts, Anypoint Runtime
Fabric uses the Persistence Gateway.
To manage data persistence across Mule application replicas and restarts, Anypoint Runtime
Fabric uses Persistence Gateway
Tokenization Service Supported Supported

25. Runtime Fabric Manager - Benefits
• Reduce Infrastructure Cost - Amount of Infrastructure required for setting up and
managing the Runtime Fabric Manager is to reduce footprint.
• More visibility to operation teams for managed Kubernetes environments
and Self-Managed Kubernetes service providers like AWS and Azure offered Auto
Scaling, automatic Kubernetes upgrades and monitoring.
• Kubernetes controller is managed by Self-Managed Kubernetes service providers
like AWS and Azure.
• Flexibility of choosing own ingress load balancer and preferred linux-based
operating system in case of Self-Managed Kubernetes.
• Isolation between applications by running a separate Mule Runtime per
application.
• Ability to run multiple Mule Runtime on same sets of resources.
• Cheaper to run mule applications longer term compared to CloudHub as apps can
be deployed with as low as 0.02 Core (CloudHub is 0.1 vCore minimum)
• Applications deployed on Runtime Fabric Manager can be managed by Anypoint
Runtime Manager.
• Scaling the application across the multiple replicas with Zero downtime.
• Intelligent Healing and Automated application failover.r

26. Q & A

27. Take a stand !
18
●Nominate yourself for the next meetup speaker and suggest a topic as well.

28. 20
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/surat
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?

29. 20
● 11th June 2022 - Implementing and Understanding SAGA (Orchestration and
Choreography) Patterns With MuleSoft
● 24th June 2022 - Combine Service Mesh With Anypoint API Management to
power Microservices
● 9th July 2022 - Driving Digital Transformation in Banking Industries With
MuleSoft
Upcoming Meetups

30. Quiz Time
Get ready to WIN a Special Gift from MuleSoft Community

31. Thank you