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:
- Ingress documentation from Kubernetes.io: this is Azure agnostic ; it explains the concepts & give generic examples
- Azure AKS documentation online: there are multiple articles on Ingress covering different topics ; this gives example on AKS
- 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:
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:
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.
Another one is hosting multiple domain names on the same ingress (e.g. public IP) using host name for routing.
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.
Conceptually, the communication pattern goes a bit like this:
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.
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.
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.
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.
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.