The city still runs ingress-nginx for legacy portals. What is the purpose of an Ingress resource in that model?
Select an answer to reveal the explanation.
Short Explanation
An Ingress object is the routing wishlist—hosts, paths, backends—while the Ingress controller is the worker that makes those rules real. By itself, the Ingress YAML is just instructions for that controller.
Full Explanation
In the classic Ingress model still used for many city legacy portals, an Ingress resource declares HTTP routing intent—hosts, paths, and backend Services—while an Ingress controller watches those objects and programs its data plane. The Ingress is the routing wishlist; the controller is the worker that makes rules real. Traffic then reaches ClusterIP (or other) Services and onward to Pods. That separation is why Ingress YAML alone never opens ports until a controller claims it.
Ingress does not allocate PersistentVolumes for hostnames; storage is orthogonal to HTTP routing. It does not replace kube-apiserver authentication for north-south requests—edge auth may be added by controllers or apps, but Ingress is not the API server identity plane. It does not schedule CoreDNS replicas onto nodes matching an IngressClass name; IngressClass selects which controller handles the Ingress, not DNS placement.
Exam caveat: without a running controller (and often a correct IngressClass), Ingress objects sit unused. Annotations may add vendor behavior but are not required to understand the core purpose of the resource.
Operational check: kubectl get ingress, confirm an Ingress controller Deployment is Ready, verify the Ingress shows an address if expected, and curl the municipal host through that entrypoint to the named backend Service.