In this blog post, we will discuss, how to use Azure API Management as an ingress point for AKS services, that are not exposed publically and how other services in the Kubernetes cluster can use the same API Management instance to communicate with these APIs while leveraging the power of API Management’s policies even for internal requests.

Why would you want that?

Well, if you have a bunch of transformation and throttling rules already configured in your public facing API Management, you might want to re-use the same rules for internal communication. Setting up a second API Management just for internal use and synchronizing all configs is not the best option obviously.

If you want to follow along but don’t have an application at hand to test this on, feel free to use my tiny GitHub sample, that I also used for this post.

Advertisement Block: I will buy myself a pizza every time I make enough money with these ads to do so. So please feed a hungry developer and consider disabling your Ad Blocker.

Connect API Management to your AKS Network

Assuming you have just created the AKS cluster and an API Management instance in Azure, we need to set up the networking first. Navigate to the Resource Group that has been created for your AKS resources and open the Virtual Network that hosts your nodes. Make sure to add two additional subnets. One for the API Management instance and one for the API service in Kubernetes.

Screenshot of Creating two additional Subnets in the AKS VNET

Now we need to ensure, that your API Management instance can talk to that VNET. So open your API Management in Azure, navigate to the Virtual Network settings and a new external network connection to the network in which we just created the subnet for API Management.

 Note, that not all of the API Management pricing tiers have VNET support!

Screenshot of Connecting the API Management with the created subnet

Next, we want to make sure that the Kubernetes Service exposes the API service to the other subnet we created. To ensure that, we can use the service.beta.kubernetes.io/azure-load-balancer-internal annotations as described in the documentation. The service description in your manifest should be of type LoadBalancer and now look like this:

Hint: In case you are facing traffic spikes with this solution, it is probably not the API Management but more likely the additional hops from node to node in Kubernetes internally, if not all nodes host your service. To solve this, you can use NodePort instead of LoadBalancer and add additional traffic policies inside the Kubernetes Service.

After the deployment, we should see the VNET IP address of the API service using the kubectl get service api command. This is the IP address we can use, to configure API Management.

Console output of the Console output of the kubectl get service command showing the IP address 10.0.1.4

Configure API Management

Create a new API in your API Management instance and use the service’s IP address as the Web service URL in the configuration blade.

Two screenshots of creating a new API in API Management and creating a new GET operation in it.

Call the API from other AKS services through API Management

If you want to use the same API Management logic for internal requests to your APIs too, you can do that. I would recommend creating separate Products for internal and external requests if you want to avoid throttling for internal calls for example.

As Azure handles network traffic with “cold potato routing”, you will not leave the Azure data center’s network when calling one Azure service from another in the same region. That means if you call https://your-api-management.azure-api.net from one of your services in your AKS cluster, the request will be handled by Azure internally without leaving the data center.

A full Kubernetes manifest file with a Web Frontend that gets published externally and an API, which only exposes itself to the AKS VNET but is reachable through API Management could look like this:

This has been taken from a super tiny sample application, that I have published on GitHub.


Robin-Manuel Thiel

At daylight, Robin-Manuel talks about new IT trends and development. But at night he turns into a tinker and developer which sometimes leads to insufficient sleep. He loves cool technologies, cross-platform and everything with a power-plug or IP address.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.