Using Multiple Ingress Controllers in Runtime Fabric

byGonzalo Marcos -

In our previous post, we saw how to install 2 NGINX ingress controllers in an EKS cluster - one for external traffic and one for internal traffic. In this post, we’ll install Runtime Fabric on that EKS cluster and see how to set up our RTF instance so that we can deploy mule apps exposed external and internally.

Prerequisites

We’ll start from that previous post where we installed and configured:
  • An AWS EKS cluster
  • 2 NGINX ingress controllers - one internal and the other one internet-facing
On that cluster, we need to:
Once we’ve got that, what we need to do is to work with the Ingress Resource Template. We’ll create two templates, one per each controller. If you don’t know how the ingress resource template works for RTF check out this post.

Create Ingress for external 

  • To create the RTF ingress template for the external ingress, first create a file rtf-nginx-external.yaml and paste the following
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
rewrite ^/app-name(/|$)(.*) /$2 break;
name: rtf-ingress-external-template
namespace: rtf
spec:
ingressClassName: rtf-nginx-external
rules:
- host: rtf-external.gon.com
http:
paths:
- path: /app-name
pathType: ImplementationSpecific
backend:
service:
name: service
port:
number: 80

  • Notice
    • In annotations - The nginx annotation is used by NGINX to do the path-based rewrite rule. 
    • ingressClassName - This is the RTF template, so in this field we need to add the rtf prefix to the ingress class of the controller we want to use (nginx-external). This way, every time we deploy an app using the endpoint of the external controller, RTF will take this value, remove the prefix and create the real ingress with the correct ingressClass.
    • host - This would be a DNS name that resolves to the public IP of the external ingress controller. It could be the public DNS name provided by AWS for the load balancer or it could be an alias with your custom domain that points to that. If you use that, as you can imagine, this alias needs to be public and available in internet.
    • rules - In this section we specify the ingress rule. The rule sets that all the requests received at http://rtf-external.gon.com/[app-name] will be redirected to http://[app-name] which is the name of the service deployed for our mule app.
  • Run the following command to create the ingress template
kubectl apply -f rtf-nginx-external.yaml


Create Ingress for Internal

  • We’ll follow the same procedure. First, we will create a file rtf-nginx-external.yaml and paste the following:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
rewrite ^/app-name(/|$)(.*) /$2 break;
name: rtf-ingress-internal-template
namespace: rtf
spec:
ingressClassName: rtf-nginx-internal
rules:
- host: rtf-internal.gon.com
http:
paths:
- path: /app-name
pathType: ImplementationSpecific
backend:
service:
name: service
port:
number: 80
  • Notice:
    • In annotations - The nginx annotation with the same path-based rewrite rule. 
    • ingressClassName - In this case we will use the other ingress controller, so we have to use the ingress class of that controller (nginx-external) with the rtf prefix(rtf-nginx-external).
    • host - In here we need to use the DNS name that resolves to the private IP of the internal ingress controller. That’s the DNS name provided by AWS. But we could use anything that the local DNS in the internal network resolves as the private IP of the internal ingress controller.
    • rules - In this section we specify the ingress rule. The rule sets that all the requests received at http://rtf-external.gon.com/[app-name] will be redirected to http://[app-name] which is the name of the service deployed for our mule app.
  • Create the ingress template with the command below
kubectl apply -f rtf-nginx-internal.yaml
  • Now, if we get back to the Anypoint platform, we’ll see that we’ve got two Base Endpoints in the Inbound Traffic of our RTF cluster:


Deploy 2 Apps - one internal and one external

Let’s test all of this configuration. For that we’ll deploy two mule apps - one per each public endpoint
  • Internal app
    • Deploy a simple app (we can take the HelloWorld app from Exchange provided by Mulesoft)
    • In the Ingress tab, notice that now there are two Public endpoints for our app. Choose the external public endpoint.

    • Deploy the app
    • Once the app is deployed, we can test it from our computer, as the public endpoint should be available in internet.
    • For testing purposes, like this tutorial, we can fake the public dns record adding manually the record to our /etc/hosts file

  • External app
    • Deploy another simple app (we can take the same HelloWorld app, the app is not relevant)
    • In the Ingress tab, now choose the internal public endpoint.

    • Deploy the app
    • Once the app is deployed, to test it we need to do it from within the network segment of the EKS cluster. For that, we can deploy an EC2 instance in the same VPC of the EKS and we can ping or curl the internal endpoint.



You may like these posts

Previous Post Next Post