In a previous post, we went through some scenarios in K8s where we would install multiple Ingress Controllers for our cluster. Now, in the context of Mulesoft and Runtime Fabric, the question is - do any of those scenarios apply to Runtime Fabric? When should we think of installing multiple ingress controllers for our Runtime Fabric instance(s)?
Here are some considerations:
Here are some considerations:
Environment Segmentation
- When we have multiple environments in our Anypoint Platform, the best practice is to have minimum two RTF clusters - one cluster for Production and another one for non production environments. For non production environments, each environment might have its own ingress controller to manage traffic independently. This ensures that traffic from development does not accidentally impact the staging environment (and viceversa), and each environment can be tailored with specific configurations.
- Although not recommended, in those cases in which we can only afford one RTF cluster for production and non production environments, each environment should have its own ingress controller to isolate production and non production traffic within the cluster.
Internal Vs External Traffic Segmentation
There are different types of traffic in the context of a Runtime Fabric cluster:- Traffic within the RTF cluster - In the context of an API led connectivity the traffic between experience → process and process → system APIs does not leave the K8s cluster. We don’t really need an Ingress controller for this, applications within the traffic can be accessed directly via the app name - each app in RTF will create a Cluster IP Service with the name of the app.
- Internal Traffic - This would be the traffic between mule apps within the RTF cluster and applications/services located outside the cluster but within the same VPC or network segment where the cluster is running. In this case, we could create an Ingress controller for RTF that would provide a Private Endpoint in the cluster. This way, applications/services in the same VPC or any consumer located in the local network can consume our APIs without exposing them to the public internet. This would be also the case of another network segment (connected via a VPN/Transit Gateway) accessing our mule apps in RTF
- External Traffic - This would be the traffic coming from outside our network. In this case, it would be very beneficial to create an ingress controller only for those applications that would be public facing, as opposed to having only one ingress controller exposing all the mule apps in the cluster.
Multi-Tenancy
- Another possibility is having multiple Runtime Fabric instances sharing the same K8s cluster.
- In this scenariom, a cluster is shared by multiple tenants, such as different teams, departments, or customers, each requiring isolation.
- In this case, it would be recommended to have one ingress controller per each production environment (assuming the RTF cluster hosts only the production environment of each RTF instance), to manage their specific traffic, allowing custom configurations, security policies, and resource limits tailored to each tenant's needs.
Geographical Segmentation
- When the list of our API consumers is distributed across multiple geographical regions, we might want each region to have its own ingress controller to apply different rules and WAF features differently. For example, with an ingress controller per region, we could provide a public endpoint per region and make that public endpoint only available within that region with firewall/routing rules. This way, at deployment time we could choose to which region the app would be available.
Audience Segmentation
- Typically, only our experience APIs would be exposed outside our RTF cluster. But that does not mean all these APIs should be publicly available.
- We might organize all these exp APIs in groups of APIs, where each group would be provided by an endpoint and specific rules. For example:
- Internally, we could provide a Private endpoint per Department, Project or Business area
- Externally we could provide different Public endpoints for Customers, Partners, Employees...