A request from the internet to a Pod
Follow one request to shop.example.com/checkout. First the browser resolves the name through public DNS to the IP of the cloud load balancer (created by a LoadBalancer Service or by the Gateway). The request then reaches the Gateway or Ingress controller, which terminates TLS and matches the host and path against its routes.
The matching route points at the Service checkout. Inside the cluster, the controller resolves the Service name through CoreDNS, or is configured with the Service's endpoints directly, and the request is sent towards the Service's virtual IP, where kube-proxy rules (or the CNI's eBPF datapath) translate it to the IP of a ready Pod chosen from the EndpointSlice. The response flows back the same way.
Each hop has a distinct failure signature, which is how you debug it. A name that does not resolve is DNS. A connection that times out at the load balancer points to security groups or the load balancer. A 404 from the gateway means no route matched. A 503 usually means the Service has no ready endpoints. A connection reset from the Pod points at the application or a NetworkPolicy.
Many controllers send traffic directly to Pod IPs, skipping the Service's virtual IP, for better load balancing and to preserve the client address. GKE container-native load balancing with NEGs and the AWS Load Balancer Controller's IP target mode are examples (Decks 2 and 3).