Deploying an API to MuleSoft Flex Gateway running in Oracle Container Engine for Kubernetes

In my last article (you can find it here), I went through the process of installing the Flex Gateway in the Oracle Container Engine for Kubernetes. As you can perceive I like to work a lot with Oracle Cloud Infrastructure and with MuleSoft, and part of my work is to continue writing about how those two can work together.

Flex Gateway is a good example because it can get deployed in Kubernetes, in my case: Oracle Containers for Kubernetes.

Let’s just remember the two modes on how the Flex Gateway can work:

1. Connected mode
2. Local mode

Taken from https://blogs.mulesoft.com/news/anypoint-flex-gateway/

In Connected mode, you can manage and deploy the API from within Anypoing Platform’s control plane. And as you could have read in my previous article, the process can be performed for running the Flex Gateway directly on top of a Linux Server, inside a Docker container, or in Kubernetes.

But for Kubernetes you have two alternatives:

1. Since the Flex Gateway can be deployed in a Docker container, you can manage it in Kubernetes just as any other application. In this case, you will use the connected mode.
2. Or as Ingress Controller for your Kubernetes cluster. This option is just available for Local mode. I’ve not written an article about this mode yet, but I will in the next few days. In the previous image you can notice this, look:

Taken from https://blogs.mulesoft.com/news/anypoint-flex-gateway/

In this article, we will go through the process of creating a new API using MuleSoft API Manager, and deploying it to a Flex Gateway running in connected mode using Oracle Containers for Kubernetes.

The process is very straightforward but it contains one step that you should understand to make it work.

Also, let’s keep in mind that the whole idea of having the Flex Gateway running inside Kubernetes, is to manage and/or expose APIs that are running inside the cluster but that you want to make available for external access. The normal use case is that your microservices can be exposed through the Flex Gateway, and use it as your ingress for applying policies.

The process we will follow for creating the API and deploying it, is:

1. We have a microservice running inside my Kubernetes cluster but is only accessible for applications inside the cluster
2. We want to expose that microservices as an API through the Flex Gateway that is already deployed in the cluster
3. Using MuleSoft API Manager, we will create the API, point it to the microservice and deploy it to the Flex Gateway
4. Using kubectl we will update the Flex Gateway service to open the port for our newly created API.

In our Oracle Container Engine for Kubernetes cluster we have:

(The session-API is our microservice, the owner of that code is my friend Ricardo Ortega, you can find it here: https://github.com/manraog/redis-session-api.git)

At the services level:

The way we can get access to the microservice is just internal from the cluster itself. That is, only applications deployed inside the cluster can reach it through the cluster IP.

For example, if I get inside the pod of our Flex Gateway and try to connect to the microservice through the cluster IP, I should be able to do it. Let´s try it:

Or if you go inside the microservice pod and try this:

Or by name:

Good enough. We have validated that within the cluster we can reach the HTTP endpoint of our microservice, now is time to create the API and deploy it to the Flex Gateway, which is our ultimate goal.

Go to API Manager:

Click on Add API:

We select Flex Gateway and the one we installed using the steps of my previous article. Then click on Next and go to the next screen:

Select Create new API, give it a name (Session API in my case), and for Asset type select HTTP API. Then click on the Next button.

Give an API instance Label. Also type the implementation URI, in our case: http://session-api/ which is what we had tested already and that is reachable through the Flex Gateway pod. And finally, for the Base Path, just type: /

Then, in that same configuration screen there is an option for advanced configuration:

That port is the one where our API will be serving. That port needs to be opened on your Loadbalancer (in our case an Oracle Cloud Infrastructure Load Balancer). Every single API needs to consider this. In this mode, we have to do this.

Finally, click on next and in the final screen:

Click on Save and Deploy.

If you are curious about what happened at the Flex Gateway log level, get the logs and you will see something like this:

Now, we just need to tell our Flex Gateway Service at Kubernetes that we need to open a port (9081). To do that, just execute:

kubectl -n gateway edit svc ingress

And a text editor will appear. To add the port, we need to add an entry to the configuration. For example:

ports:
- name: http
nodePort: 30077
port: 80
protocol: TCP
targetPort: 80
- name: https
nodePort: 32706
port: 443
protocol: TCP
targetPort: 443
- name: myAPI
port: 8081
- name: mySessionAPI
port: 9081

At your LoadBalancer Security List (in my case I am using Oracle Cloud), a new rule had to be added:

And if you check the configuration for services in the namespace where the gateway is deployed, you will notice this:

Now is time for testing.

We can use curl for that purpose. We will use our load balancer IP to make a request to our API, and this should route it to our Flex Gateway and ultimately, to our microservice:

As you can see in the image, the microservice is serving through the API we’ve exposed using our MuleSoft Flex Gateway.

I will continue working with the Flex Gateway, stay tuned for more articles.