This article was brought to you by @kumarallamraju
In the Kubernetes world there are different ways to get internal and external traffic into your Kubernetes cluster. As an example we have
ClusterIP: default Kubernetes service accessible inside the Kubernetes cluster - no external access
NodePort: most primitive way to get external traffic directly to your service. As the name implies, it opens a specific port on all the Nodes (the VMs) and any traffic sent to this port is forwarded to the service.
LoadBalancer: standard way to expose a service to the internet. In Azure, this will spin up an Azure Load Balancer (L4) that gives us a single public IP address that forwards all traffic to your service.
Ingress: Unlike all the above examples, Ingress is not actually a type of service but acts as a smart router or entry point into your cluster. We can do several things with an Ingress, and there are many types of Ingress controllers with varying capabilities (Istio, Contour, Traefik, NGINX). One of the popular ones and widely used is NGINX ingress controller. Ingress is more useful if you want to expose multiple services under the same IP address, and these services all use the same L7 protocol. You only pay for one load balancer price.
With the brief introduction on Load Balancer types, I wanted to talk about a new solution from Azure that binds the Azure Kubernetes Service (AKS) with Application Gateway. This solution provides an open source Application Gateway Ingress Controller, which makes it possible for AKS customers to leverage Application Gateway to expose their Kubernetes services to the internet.
Application Gateway Ingress Controller runs in its own pod on the customer’s AKS.
Much like the most popular Kubernetes Ingress Controllers, the Application Gateway Ingress Controller provides several features, leveraging Azure’s native Application Gateway L7 load balancer. To name a few:
The architecture of the Application Gateway Ingress Controller differs from that of a traditional in-cluster L7 load balancer. The architectural differences are shown in this diagram:
An in-cluster load balancer performs all data path operations leveraging the Kubernetes cluster’s compute resources. It competes for resources with the business apps it is fronting. In-cluster ingress controllers create Kubernetes Service Resources and leverage kubenet for network traffic. In comparison to Ingress Controller, traffic flows through an extra hop.
Application Gateway Ingress Controller leverages the AKS’ advanced networking, which allocates an IP address for each pod from the subnet shared with Application Gateway. Application Gateway Ingress Controller has direct access to all Kubernetes pods. This eliminates the need for data to pass through kubenet.
terraform apply out.plan
As a result of Application Gateway having direct connectivity to the AKS pods, the Application Gateway Ingress Controller can achieve up to 50 percent lower network latency vs in-cluster ingress controllers. Application Gateway is a fully managed service, backed by Azure virtual machine scale sets. Application Gateway Ingress Controller does not use AKS compute resources for data path processing. It does not share or interfere with the resources allocated to the Kubernetes deployment. Auto-scaling Application Gateway at peak times, unlike an in-cluster ingress, will not impede the ability to quickly scale up the apps’ pods. And of course, switching from in-cluster L7 ingress to Application Gateway will immediately decrease the compute load used by AKS.
Application Gateway Ingress Controller is now stable and available for use in production environments. The project is maturing quickly, and we are working actively to add new capabilities. We are working on enhancing the product with features that customers have been asking for, such as using certificates stored on Application Gateway, mutual TLS authentication, gRPC, and HTTP/2. We highly encourage you to give it a try and provide your valuable feedback