Full lesson
Explore the full explanation, examples, and visuals at your own pace.
A public request enters the cluster
A browser doesn’t reach the application Pod directly. For https://shop.example/products, it sends HTTPS to the public load balancer, the reachable entry point before traffic enters the cluster. That distinction matters: the load balancer exposes an entry, while Kubernetes routing decides where the request goes next.
The entry hands off to HTTP routing
The browser’s HTTPS request reaches the load balancer, which hands it to the Gateway inside the cluster. That’s the HTTP routing entry; Ingress is an alternative API, and a controller implements the routing configuration.
The path selects the shop Service
The browser’s request reaches the Gateway through the load balancer. The Gateway matches the /products path and routes it to the shop Service, a stable backend name that stays the target even as the application Pods behind it change.
The Service reaches an application Pod
The load balancer brings the browser’s HTTPS request to Gateway; Gateway routes /products to shop, and the Service forwards it to a ready Pod.
For a request to the products path, which component chooses the shop Service?
Let's think this through. For a request to the products path, which component chooses the shop Service? A: The application Pod. B: The Gateway or Ingress implementation. C: The shop Service. Choose an answer, or just think it through. I'll explain in a moment.
- The application Pod
- The Gateway or Ingress implementation
- The shop Service
For a request to the products path, which component chooses the shop Service?
The answer is B: The Gateway or Ingress implementation. The Gateway or Ingress implementation applies the HTTP path rule and chooses the backend Service. The Service then forwards traffic to an eligible Pod; it does not choose a backend from the URL path.
- The application Pod
- The Gateway or Ingress implementation
- The shop Service
One request, then its response
The browser sends GET /products to the load balancer, which forwards it to the Gateway. The Gateway routes it to shop, and the Service forwards it to a Pod. That Pod creates the application response. The return arrows simplify the network hops back through the Gateway to the browser.
A stable Service can target multiple Pods
The Gateway still routes /products to shop, and shop can now send the request to either ready Pod A or ready Pod B. Adding Pod B doesn’t change the target; only ready Pods are eligible to receive traffic.
Roles to keep distinct
The load balancer exposes the entry point; Gateway or Ingress matches slash products to shop; then the Service selects a ready Pod. Where these pieces run varies by cluster.
- LB exposes the entry point
- Gateway or Ingress applies HTTP routing
- Service targets ready application Pods
Public entry to ready application Pod
The load balancer exposes an entry point; Gateway or Ingress chooses a backend by HTTP rules; a Service provides a stable target and selects a ready Pod.