I will share my experiences with a design and implementation of Azure Application Gateway for an Azure Kubernetes Service (AKS) cluster. This is so that you may get some practical insight as you plan and design for using the Azure App Gateway.

In this blog series, I will go over

1. Fundamental Ingress concepts
2. Architecture and deployment components
3. My review, observations and insights

Typical Use Case: For an application that is required to be internet facing, it is recommended to have a networking appliance that allows for ingress traffic into your application where you can manage web security, networking and http/layer 7 traffic.

As a result, a valuable option is to leverage the Azure Application Gateway as part of your overall Azure Kubernetes system architecture.

My implementation was based on the following documentation. So read the following article to further understand background details.

• https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/docs/setup/install-new.md

The fundamentals of an Ingress and an Ingress Controller.

For me, this was a harder concept to understand as there are many many online documentation and articles explaining them a bit differently. This is understandably so because there are many ways approaches in handling internet traffic to access your application and it depends on some factors. But let’s just

In order for web traffic to access your application through http and https routes in the Kubernetes pods and service, you need to have an ingress and ingress controller.

So here is a summary of statements taken from the Kubernetes documentation

Ingress

• Ingress exposes HTTP and HTTPS routes from outside the cluster to services that are within the cluster.
• Traffic routing is controlled by rules defined on the Ingress resource.

I basically see the Ingress resource as a definition of the http(s) routes and other configuration but does not implement them. This is for the job of the Ingress Controller.

Ingress Controller

• An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer
• You must have an ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
• An example that implements the ingress controller, that can be deployed, is the popular Nginx which runs as a pod in your Kubernetes cluster. However, the focus of this blog is to review Azure App Gateway as the ingress controller. To see other ingress controllers that can be deployed read https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/#additional-controllers

Searching for an appropriate diagram that I find clearly illustrates these concepts is taken from a couple slides from this presentation deck

Image Credit: https://www.slideshare.net/AineLong/nginx-kubernetes-ingress-controller-getting-started-emea3

I like to point out that this diagram does a good job clarifying the role of the Ingress Controller vs the NGINX load balancer. I find many online articles and diagrams refer to both as one construct, in the scenario of using NGINX within Kubernetes.

In summary there are three components that work together – ingress, ingress controller and the load balancer. Sometimes it is not as clear in other articles and diagrams found online. In the case of the App Gateway, this is the load balancer of which the App Gateway Ingress Controller (AGIC) is in a pod that configures the App Gateway in order to implement the ingress traffic routes. For AKS and a standalone Kubernetes, does not offer an ingress controller out of the box. It is left to the designer to fill this gap. In the next blog post I will go over AGIC implementation details.

In the next blog post, I will go over AGIC architecture components, my opinion, tips and recommendations.