Bhakta Thapa

Part of the series Kubernetes networking

Kubernetes Ingress: How web traffic finds the right Service

, 4 min read

Imagine a large apartment building. A visitor arrives and tells the lobby desk which apartment they want. The desk checks the address and sends the visitor to the right door.

Kubernetes Ingress works in a similar way. It describes how incoming HTTP or HTTPS requests should be matched and sent to the correct Service.

What each part does

Part Job in this example
Ingress The routing directions for incoming web requests.
Host name The building’s address, such as shop.example.com.
Path The route inside that address, such as /menu.
Service The stable door in front of the application.
Service port The port the Service uses to receive traffic.
Ingress controller The component that reads Ingress objects and handles the traffic.

For example, a visitor might request:

http://shop.example.com/menu

An Ingress rule can say: when the host is shop.example.com and the path starts with /menu, send the request to menu-service on port 80.

Watch the request flow

The animated diagram follows one request from the browser to the application and back. Use Play to see the request token move through the path, or Next to study each stage. The dashed line is configuration: the controller reads the Ingress rule. It is not an extra network hop.

Open the Ingress request-flow diagram in a full browser tab.

How the request travels

  1. A user opens a web address. The browser prepares a request for shop.example.com/menu.
  2. DNS resolves the host name. The browser learns the address of the cluster’s external entry point. DNS is a lookup; the HTTP request does not travel through the DNS server.
  3. The request reaches the Ingress controller. The controller is the traffic-handling component, often exposed through a load balancer or another external entry point.
  4. The controller checks the host and path. It reads the routing rules represented by the Ingress object.
  5. The matching rule selects a Service and port. In this example, /menu selects menu-service:80.
  6. The Service selects a ready Pod endpoint. Kubernetes forwards the request to the application Pod.
  7. The response returns along the data path. The application responds through the Service and controller to the browser.

Important: An Ingress resource holds routing directions. An Ingress controller is the component that reads those directions and handles traffic. Without a controller, the directions may exist, but nobody is there to follow them.

A simple Ingress example

This example sends requests for /menu on shop.example.com to a Service named menu-service on port 80:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-menu
  namespace: store
spec:
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /menu
            pathType: Prefix
            backend:
              service:
                name: menu-service
                port:
                  number: 80

Here, Prefix can match /menu and paths that continue under it, such as /menu/lunch. The Ingress and its destination Service are in the same namespace, so the Service name is resolved within store.

This manifest describes a route. It does not install an Ingress controller, provision a public address, create DNS records, or provide TLS certificates.

A reliable way to solve an Ingress task

Before writing YAML, find the important details in the task:

  1. Where does the Ingress belong? Find the namespace.
  2. What address should it match? Find the host name.
  3. What part of the address should it match? Find the path and choose the required pathType.
  4. Where should traffic go? Find the Service name.
  5. Which Service port should it use? Use the port listed for that Service.

Then check the references:

Ingress host + path → Service name + port → ready Pod endpoint

The Service must be in the same namespace as the Ingress. A route can look correct and still fail if the Service port, selector, or endpoints are wrong.

Check the result

After creating the resource, inspect the route and the backend:

kubectl get ingress -n store
kubectl describe ingress shop-menu -n store
kubectl get service,endpointslice -n store

If the controller publishes an address, test the configured host. For a local test, send the host header to the controller’s address:

curl -H 'Host: shop.example.com' http://INGRESS_ADDRESS/menu

A 200 response is useful evidence that the request reached the application, but it is not the only check. Also inspect the Ingress events, controller logs, Service selector, ready endpoints, and application response.

Symptom First things to inspect
Host name does not resolve DNS record and the controller’s published address.
Connection times out External exposure, firewall rules, controller, and load balancer.
No rule matches Host, path, path type, namespace, and controller configuration.
Controller reports an upstream error Service name, Service port, selectors, and ready EndpointSlices.
The route works but the response is wrong Application path handling, rewrite settings, and controller-specific annotations.

What to remember

Ingress matches the host and path, then sends traffic to a Service and its port.

Think: address → route → Service door → Pod.

Ingress is a useful routing API, but the controller and the rest of the traffic path still matter. Start debugging at the entry point, follow the matching rule, and verify the Service’s actual ready endpoints.