How User Requests Travel in Kubernetes

End-to-end flow: User browser → DNS → Load Balancer → Ingress Controller → Kubernetes Service → kube-proxy/IPVS/iptables → Application Pod → Response. Covers each component role and common debugging points.

Overview

From browser to Pod and back

Knowing how a user request travels from a browser to a Kubernetes Pod is essential for architecture decisions and incident debugging. Several components participate, each with a distinct role.

The edge: DNS and the load balancer

1 — DNS — Resolves the domain (for example api.example.com) to the IP of a cloud load balancer or the Ingress controller's LoadBalancer Service
2 — Load balancer — AWS ALB, GCP GLBC or Azure Application Gateway distributes TCP/HTTP connections across nodes running the Ingress controller Pods

The Ingress controller

An Ingress controller (nginx-ingress, Traefik, AWS ALB Ingress, Istio Gateway) runs as a Pod. It reads Ingress objects from the Kubernetes API and programs its routing table.

TLS termination — Certificate from cert-manager or ACM
Virtual host routing — host: api.example.com
Path-based routing — /v1 to service-v1, /v2 to service-v2
Edge policy — Rate limiting, auth headers

Service, kube-proxy and the Pod

4 — Service — A stable abstraction that does not run the application; tracks healthy Pods via Endpoint objects
5 — kube-proxy, iptables, IPVS — Rewrites the ClusterIP destination to a healthy Pod IP, random or round-robin, in kernel space on the receiving node
6 — Application Pod — Processes the request; the response reverses through the same iptables/IPVS rules

> [!IMPORTANT] The user never connects directly to a Pod. LB, Ingress, Service, Pod exists to decouple stable access points from volatile compute.

Debugging order

> [!TIP] Debug inside-out: start at the Pod and move toward the edge, one layer at a time.

Key concepts

Ingress Controller: A Pod running a reverse proxy (nginx, Traefik, HAProxy) that reads Ingress objects and programs its own routing table. It provides TLS termination, virtual hosting, path routing, and often auth/rate-limiting. It is NOT built into Kubernetes — you deploy it separately.
Kubernetes Service: A stable virtual IP (ClusterIP) and DNS name. Does NOT run the application — it is a load balancing abstraction that selects healthy backend Pods by label. The Endpoints controller keeps the list of Pod IPs current.
Endpoints object: Automatically maintained by Kubernetes. Lists the IP:port of every ready Pod matching the Service selector. kube-proxy reads this to program iptables/IPVS. If no Endpoints, the Service has no backends and traffic fails.
kube-proxy DNAT: Destination Network Address Translation. kube-proxy writes iptables/IPVS rules that rewrite the Service ClusterIP to a real Pod IP when a packet arrives. Happens in kernel space, transparent to the application.
TLS termination at Ingress: The Ingress Controller decrypts HTTPS traffic using a TLS certificate (from Kubernetes Secret, cert-manager, or cloud ACM). Traffic from Ingress to the backend Service is typically plain HTTP inside the cluster.
Gateway API: The successor to Ingress in Kubernetes. More expressive: HTTPRoute, TCPRoute, GRPCRoute resources with richer traffic policies. Supported by Istio, Envoy Gateway, Cilium. Not yet universally adopted but the direction for new clusters.

When to use it

Debugging "my app is not reachable" incidents systematically without guessing
Architecture review of a new Kubernetes deployment — ensuring each layer is correctly configured
Interview questions about Kubernetes networking from the application perspective
Explaining to a developer why changing a Pod label broke their deployment's traffic
Choosing between Ingress, Gateway API, and Service of type LoadBalancer

Interview questions

Trace a user request step by step from browser to Kubernetes pod.
Why does a Service with a correct selector still show no Endpoints?
What is the difference between a Service of type LoadBalancer and an Ingress?