How does a Network Load Balancer work with an Ingress Controller in Kubernetes (AWS/EKS)?

Question

Is my understanding of the following workflow correct:

1. When a request goes to the Load Balancer, it will also go through the Ingress Object (essentially a map of exactly how to process the incoming request).

2. This request is then forwarded to an Ingress Controller to fulfil (the request ultimately gets sent to the appropriate Pod/Service).

But what happens when there is only one Ingress Controller? It seems to me that the purpose of the load balancer will be defeated as all the requests will go to EKS Worker Node - 1?

And additionally, let's say that Pod A and Pod B in EKS Worker Node - 1 is occupied/down, will the Ingress controller forward that request to EKS Worker Node - 2?

Is my assumptions correct? And should you always have multiple ingress controllers across different nodes?

I'm confused as I don't understand how these two components work together? Which component is actually balancing the load?

Answer 1

To your main question, having multiple ingress controller replicas for redundancy in case of node failure is very common and probably a good thing to do on any production setup.

As to how it works: there's two modes for Load Balancer services depending on the "external traffic policy". In the default mode, the NLB doesn't talk directly to Nginx, it talk to the kube-proxy mesh on every node which then routes the Nginx pods as needed, even if they are on a different node. With traffic policy "Local", the NLB will bypass the kube-proxy mesh and only talks to nodes that have at least 1 Nginx pod, so in your example the NLB would not talk to node 2 at all.

The extra hop in the default mode improves resiliency and has smoother balancing but at a cost of hiding the client IP (moot here since the NLB does that anyway) and introducing a small bit of latency from the extra packet hops, usually only a few milliseconds.