About Ingress in Azure Kubernetes Service (AKS)


I did a bit of experimentation with Kubernetes Ingress, more specifically NGINX, lately.

I found the concept of Ingress utterly confusing at first. It is actually relatively simple. So, I thought I would share this sense of simplicity.

This article is conceptual. There will be no code nor even Portal tour.

If you want to ramp up on Ingress in AKS, I would suggest the following readings, in order:

  1. Ingress documentation from Kubernetes.io: this is Azure agnostic ; it explains the concepts & give generic examples
  2. Azure AKS documentation online: there are multiple articles on Ingress covering different topics ; this gives example on AKS
  3. Book Kubernetes in Action by Marko Luksa, specifically chapter 5: the book is available on Safari Book Online

Ingress vs Service

We discussed the integration Kubernetes & Azure Networking within AKS in a past article.

We used the following diagram to describe the anatomy of a service:

Anatomy of a Service

We described a service as offering a stable IP, load balancing a group of pods and typically realized through a replica set.

Now that we have a service that we can connect to, what is the need for Ingress?

It is a question of Layer 4 (Service) vs Layer 7 (Ingress) load balancing. A service offers TCP load balancing. An ingress understands HTTP / HTTPS. It understands the host header, the path and can handle TLS termination.

An ingress also is a reverse proxy: it generates a new HTTP requests to the underlying service.

Ingress acts as a front door to services. We can then upgrade our anatomy knowledge as follow:

Ingress Anatomy

Different use cases

Let’s look at a few scenarios.

The first one is what in Application Gateway parlance we would call URL Based routing. For instance, an ingress takes requests for http://vincentpizza.com and forwards requests under http://vincentpizza.com/offers/ to the pizza-offers service and requests under http://vincentpizza.com/menu/ to the pizza-menu service.

URL Based routing

Another one is hosting multiple domain names on the same ingress (e.g. public IP) using host name for routing.

Virtual Hosting

Of course, we could combine both previous approaches.

As the diagram suggests, an ingress has a many-to-many relationship with services. We could reuse a service in multiple rules.

Conceptual communication

Conceptually, the communication pattern goes a bit like this:

Conceptual Communication

The ingress routes traffic to a service which then route it to a pod.

An ingress controller is implemented as a Kubernetes Service of type load balancer.

This is similar to Azure Application Gateway which is implemented as a set of VMs fronted with an Azure Load Balancer.

Typically, backend services, i.e. services ingresses call into, are of type Cluster IP since they only need to be reached from within the cluster.

Azure communication

Now, how does that land in Azure?

Let’s assume we have 3 nodes (3 VMs) in our AKS cluster.

As mentioned, an Ingress Controller is a service of type load balancer. In Azure, the service is exposed through an Azure Load Balancer.

Azure Communication

Let’s assume the request gets load balanced on a pod running on node 3. The Ingress Controller applies ingress rules and determine the backend service to forward the request to.

The Ingress Controller then uses then forward the request to one of the pods. Here we assume the load balanced pod would be on the node 2.

Application Gateway as an Ingress Controller

We talked about Ingress Controller without mentioning any specific one. As often is the case with Open Source, there is a lot of choice.

Kubernetes maintains the NGINX Ingress Controller. This is the one we encountered most often in online documentations. There is even an extension of that Controller implementing WAF functionality.

The company NGINX maintains another flavour of NGINX Controller, which is a branded as more Enterprise friendly.

There is current development, at the time of this writing (mid October 2018), of an Ingress Controller that will integrate with Azure Application Gateway. Application Gateway will therefore be an option as an Ingress Controller sitting outside the AKS cluster.

Summary

We did a brief tour of what Ingress means within Kubernetes and how it lands in AKS.

We recommend going through the documentation we provided at the beginning of the article to acquire more depth.

Advertisements

2 thoughts on “About Ingress in Azure Kubernetes Service (AKS)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s