E4: AWS Load Balancer Controller as an Ingress Controller

In this episode, I want to discuss how the AWS Load Balancer Controller behaves when acting as an Ingress Controller.

When people think about ingresses on Kubernetes, they are commonly imagining them as the entrypoint into the cluster that also lives inside the cluster. Often represented in diagramms such as the one below.

Here the traffic arrvies in our cluster, the ingress forwards it to a service of type ClusterIP which then hands it of to the pods. The service can be of type ClusterIP since it doesn’t have to be accessible from outside the cluster, it’s only accessed via an Ingress that lives inside the cluster.

I also always thought of them like this, which stems from a youtube video I watched early on when I started learning about kubernetes.

This is not necessarily wrong but as it is often the case with diagramms, they don’t tell you the whole story.

An ingress is really just a set of rules to pass to a controller that is listening for them. An Ingress Controller. You can deploy a bunch of ingress rules, but nothing will happen unless you have a controller that can process them.

When you set up the AWS Load Balancer Controller as an Ingress Controller, they tell you that the service must be of type NodePort or LoadBalancer. At least when using their instance mode.

service must be of type "NodePort" or "LoadBalancer" to use instance mode

I don’t wanna go into the details about the two different modes or tell you which one you should choose, at least not in this article.

I was wondering why these services would have to be of type "NodePort" or "LoadBalancer". Setting them up as such makes them reachable from outside the cluster - but when we have an ingress in front, why would this be necessary?

I finally understood when looking at an architecture diagramm of the AWS Load Balancer Controller.

When you are using AWS Load Balancer Controller as your ingress controller, the ingress rules are fulllfilled by target groups in AWS, outside of your cluster.

The diagram from the beginning of the post would have to look more like the one below.

Here you can see that the service has to be reachable from outside the cluster, which means that we can’t use type ClusterIP but we have to use NodePort or LoadBalancer.

Lessons learned

An Ingress is just a set of rules and it’s up to the ingress controller to enforce these rules. In most cases, the first diagramm we saw will probably be correct and your ingress will be part of your cluster but it doesn’t have to be that way.
The AWS Load Balancer Controller is using AWS Target Groups to enforce the ingress rules before traffic enters your kubernetes cluster.

Closing Words

I hope got value out of this and consider leaving your email address so that you don’t miss out on any of my future posts.

This newsletter is free but if you want to encourage me to keep doing this you can buy me a coffee or buy me a coffee.