Setting Up Kubernetes (AKS) with Azure Application Gateway Ingress Controller

In this guide, we’ll walk through setting up Kubernetes on Azure (AKS) and configuring the Azure Application Gateway as an Ingress Controller.

Why AKS and Azure Application Gateway?

• Imagine you’re running a microservices architecture where each service needs its own URL path. The Application Gateway can route traffic based on URL paths, making sure each request gets to the right place. It’s like having a traffic cop directing each request to exactly where it needs to go.
• Another advantage of the Azure Application Gateway is its association with a public IP address, ensuring your DNS always points to the correct IP. This is different from the NGINX controller, where the IP address can change, and you would need to set up an External DNS to manage that.

1. Setting Up AKS

First things first, let’s spin up an AKS cluster. If you’re in the Azure portal, this is just a matter of a few clicks.

Create a New AKS Resource:
Start by creating a new AKS resource.

To simplify the process, you can leave the default values as they are. However, I had to choose the production configuration because the dev/test option wasn’t available in West Europe. Thanks, Microsoft! 🙃

Configure Node Pools
After setting up the basics, click the “Next” button to configure user node pools. The initial pool (the “system” pool) is used to manage Kubernetes itself, so we need to create a user node pool where we’ll deploy our resources. You can fill in the values as follows:

Your node pools configuration should look like this:

Networking Configuration:
Now, it’s time to configure the networking. Be sure to select the Azure CNI Node Subnet, as this is the only option that supports (AGIC) Azure Application Gateway Ingress Controller!

Finalizing Setup
The next tabs (like monitoring, tags, etc.) can be left with their default settings. Once everything is set, go ahead and create the resource!

2. Add AGIC

Once the resource is created, open it.
The quickest way to add the Azure Application Gateway Ingress Controller (AGIC) is to go to the Networking settings, then navigate to the Virtual Network Integration tab, and click the Manage button.

From there, enable the Ingress Controller, and provide a name for the new Application Gateway.

If prompted, you’ll need to specify the subnet prefix for the Application Gateway, which will be created inside the AKS virtual network.

While you apply all the settings it might take some time to complete, so be patient :)

⌛⌛⌛

When it’s done, navigate Settings -> Properties in your AKS resource. Here, you’ll find the infrastructure resource group for AKS, which is automatically created to store all AKS-related resources, including the Application Gateway.

After the AGIC integration, you should see three additional resources:

1. The Application Gateway
2. The public IP address
3. A managed identity that allows the Application Gateway to manage the virtual network of the cluster

⚠️ If the automatic creation of AGIC fails, refer to the tutorial on how to set up the Application Gateway Ingress Controller manually!

Now, let’s open the Application Gateway. You should see that it has been assigned a public IP address.

After deploying a test application into our AKS, you can access it through this public IP address.

3. Network Security Group rules

That’s not all. To make it work, we need to do one more thing: we need to create or edit the Network Security Group (NSG) settings for our subnets. It’s important to allow the specific port range required by the Application Gateway. This dynamic port range is necessary for forwarding traffic to AKS.

If you already have an NSG, great! If not, create one, and add the following inbound security rules:

• Allow ports 65200–65535

• Allow port 80 for HTTP and port 443 for HTTPS

Once that’s done, assign the NSG to your AKS virtual network subnets by editing them.

Finally, once everything is set up, our AGIC is ready to work. Let’s do a quick test!

4. Deploy the test app to your AKS.

“Let’s deploy a simple app to see how it all works. You’ll need to create a deployment, service, and ingress.

Connect to your AKS cluster.
You can find connection instructions here:

After you are connected, verify that the Ingress Controller is up and running by running the following command:

kubectl get pods -A

You can also check the logs of AGIC, which can be useful for debugging:

kubectl logs ingress-appgw-deployment-86c647c6db-r9pqx -n kube-system

While everything is up and running, let’s deploy our first pod with a sample ASP.NET app.

Here is an example of a pod and a service YAML file.
Let’s call it deployment.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: aspnetapp
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/samples:aspnetapp"
    name: aspnetapp-image
    ports:
    - containerPort: 8080

---

apiVersion: v1
kind: Service
metadata:
  name: aspnetapp
spec:
  selector:
    app: aspnetapp
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

To deploy it, run the following command:

kubectl apply -f deployment.yaml

Let’s check our deployed pod and services with the following commands:

kubectl get pod -o wide

kubectl get services

As we can see, we have a running pod with its internal IP address assigned (e.g., 10.224.0.88), and a service that points to that pod through its internal endpoint (e.g., 10.0.80.184 on port 8080). However, the application is still not accessible publicly.

To make it accessible, we need to deploy an Ingress that will forward the public traffic to the service, which in turn routes it to the pod.

Here is an example of an Ingress YAML file. Let’s call it ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
spec:
  ingressClassName: azure-application-gateway
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: aspnetapp # name of our previously created service
                port:
                  number: 8080

To deploy this Ingress, run the following command:

kubectl apply -f ingress.yaml

Once deployed, check the status of the Ingress with:

kubectl get ingress

You should see that the IP address associated with the Ingress matches the public IP of our previously created Azure Application Gateway Ingress Controller ( 52.137.54.26).

The below command will show you where the Ingress is routing traffic. As expected, it will point to the service specified in the YAML file, which ultimately routes traffic to the IP address of our pod on port 8080.

kubectl describe ingress {ingress_name}

It’s also useful during debugging to check the recent events of the Ingress to ensure there are no failures.

Now we can access our pod publicly through the browser using the AGIC public IP http://52.137.54.26 on port 80 since we haven't set up TLS for HTTPS yet. 😊

Let’s take a look at what happened in the background within our AGIC.

Once we deployed the Ingress, AGIC automatically added a new backend pool, which is pointing to our pod’s IP address.

This backend pool is associated with a rule that uses a listener. The listener is, by default, listening on port 80 for HTTP traffic because, as mentioned earlier, we haven’t set up TLS for HTTPS.

Setting up AKS with Azure Application Gateway Ingress Controller simplifies managing and securing traffic to your Kubernetes applications. With these steps, you can efficiently deploy, expose, and manage your services, paving the way for more advanced configurations like custom routing and TLS encryption. 😊

🚀🚀🚀

Additional:

• Keep in mind that if you develop your own application, the AGIC requires a health check endpoint to be provided. You can specify this endpoint in your deployment.yaml file.
• Don't forget to attach your AKS to your ACR to pull your own images

Next Steps:

• How to Set Up TLS for AGIC
  Discover how to enable HTTPS by configuring TLS for your Azure Application Gateway Ingress Controller, securing your application’s traffic.
• How to Set Up Routing for AGIC (coming soon)
  Learn how to configure routing rules in AGIC to direct traffic to different services based on paths, hostnames, or other criteria.