Full lesson
Explore the full explanation, examples, and visuals at your own pace.
GET https://api.example.com/users
DNS doesn't route the /users path; it only resolves api.example.com to the AWS load balancer's address. Then the browser sends GET /users for that host to the load balancer. Name resolution gets the request to the entry point; it doesn't choose a backend pod.
The load balancer reaches Ingress
The AWS load balancer forwards GET /users to an NGINX Ingress Controller instance in the Kubernetes cluster. Its target selection ends at ingress; it doesn’t choose among the backend replicas. The request now reaches NGINX, where ingress routing determines the destination Service.
Host and path select the Service
Once NGINX receives the request, it checks the host, api.example.com, and path, /users, against the Ingress rule. That match points to the Backend Service, not a specific pod. The Service identifies the backend; endpoint selection happens separately.
Ready replicas become eligible endpoints
The Backend Service keeps a stable name, while its EndpointSlice records the ready destinations behind it. Here, all three IPs—10.2.0.11, 10.2.0.12, and 10.2.0.13—are eligible, but none is guaranteed to receive this request.
With three ready backend pods, what does the EndpointSlice tell the ingress controller?
Let's think this through. With three ready backend pods, what does the EndpointSlice tell the ingress controller? A: The three pod IPs eligible for routing. B: Which single pod must receive this request. C: The browser's public IP address. Choose an answer, or just think it through. I'll explain in a moment.
- The three pod IPs eligible for routing
- Which single pod must receive this request
- The browser's public IP address
With three ready backend pods, what does the EndpointSlice tell the ingress controller?
The answer is A: The three pod IPs eligible for routing. The EndpointSlice identifies ready backend endpoints. It does not prescribe which one must receive this request; the routing component makes that selection.
- The three pod IPs eligible for routing
- Which single pod must receive this request
- The browser's public IP address
NGINX sends this request to one pod
The host and path match identifies the backend Service; its EndpointSlice gives NGINX the ready pod IPs. Here, NGINX proxies the GET to 10.2.0.12 and receives the response. That choice is illustrative: the Service names the destination, and NGINX typically selects among its eligible pod endpoints.
The Service IP is not always the next hop
Typically, NGINX routes directly to a pod IP; through the Service IP, Kubernetes selects the endpoint.
The response returns to the browser
The selected pod, 10.2.0.12, sends the users response back to NGINX. NGINX returns it through the AWS load balancer to the browser, completing this request’s path. That replica handled this request; another request could be routed to a different eligible pod.
Three eligible pods; one destination for this request
An Ingress rule chooses a Service; readiness defines eligible pod endpoints, while routing mode determines who selects one. Three pod IPs are eligible here, but this request goes to 10.2.0.12.