Help me trace a Request Through Kubernetes Ingress

One request uses two different pieces of routing information: DNS resolves api.example.com to the AWS load balancer’s address, then the browser sends GET /users there while retaining api.example.com as the requested host.

The AWS load balancer forwards the request to a healthy NGINX target inside the cluster. It still carries the original host, api.example.com, and path, /users, which NGINX uses to match an Ingress rule.

The browser’s GET request reaches NGINX through the AWS load balancer with its host and path intact. NGINX matches api.example.com and /users against an Ingress rule, which names Users Svc as the backend. That match selects a logical destination; the arrow doesn’t necessarily mean traffic hops through the Service.

Users Svc is associated with an EndpointSlice, which lists three ready destinations: 10.2.0.11, 10.2.0.12, and 10.2.0.13. These addresses describe eligible backends, not packets passing through the Service. A routing component can use this endpoint data to choose where the request goes.

With direct pod upstreams, the Ingress rule chooses the Service, while NGINX selects an eligible pod endpoint: 10.2.0.12 for this illustrative GET /users request.

Let's think this through. With direct pod upstreams and three ready replicas, who chooses the pod for this request? A: DNS chooses a pod IP. B: NGINX selects a ready pod endpoint. C: The browser chooses a replica. Choose an answer, or just think it through. I'll explain in a moment.

The answer is B: NGINX selects a ready pod endpoint. DNS gets the browser to the external load balancer, not a backend pod. In this direct-upstream setup, NGINX uses the backend's eligible pod endpoints to select a destination for the request.

Pod .12 handles GET /users and sends its response back to NGINX. NGINX passes that response to the AWS load balancer, which returns it to the browser. The response follows the request path in reverse.

Direct pod upstreams are an assumption here: NGINX chooses an endpoint. If it uses the Service ClusterIP, cluster networking selects the pod instead. Three replicas don't guarantee equal distribution; selection policy matters.

The Users Svc still has 10.2.0.13 listed in its EndpointSlice, but it’s marked not ready. After routing data updates, new requests can go to 10.2.0.11 or 10.2.0.12, not to 10.2.0.13.

Ingress rules select a logical backend; ready endpoints define eligible pod destinations. For this request, the rule picks the Service, then NGINX chooses a pod from its ready endpoints. In this illustrative trace, that’s 10.2.0.12.