Ingress resource vs Ingress controller

WHAT THIS TESTS A recurring source of confusion: rules versus the engine that executes them. Many candidates think creating an Ingress resource is enough.

A GOOD ANSWER COVERS An Ingress resource is purely declarative configuration: a set of rules mapping hosts and URL paths to backend Services, plus optional TLS settings. On its own it changes nothing about traffic; it is just data in etcd. An Ingress controller is an actual running component, commonly an NGINX, Traefik, HAProxy, or cloud-provider workload, that watches the API for Ingress resources and continuously reconfigures its proxy to honor those rules. Without a controller installed, Ingress resources are inert.

REQUEST FLOW An external user sends a request to the public entry point, typically a cloud LoadBalancer or a NodePort that fronts the Ingress controller. The request arrives at the controller Pod, which inspects the host header and path and matches them against the Ingress rules. It then forwards the request to the appropriate backend Service (a ClusterIP), which in turn load-balances to one of its healthy backend Pods. The response travels back along the same path.

COMMON WRONG ANSWERS Thinking the Ingress resource itself proxies traffic. Forgetting the controller must be installed separately. Skipping the Service hop and routing straight to Pods, when the controller resolves through the Service's endpoints.

LIKELY FOLLOW-UPS Where is TLS terminated? At the controller. Can one controller serve many Ingresses? Yes, that is the point. What replaces Ingress going forward? The Gateway API.

ONE CONCRETE EXAMPLE A user visits https://app.example.com. DNS points to the cloud load balancer fronting the NGINX Ingress controller. The controller matches the host to an Ingress rule sending app.example.com to the web Service, terminates TLS, and forwards to the web ClusterIP, which routes to one web Pod that returns the page.