Transit needs citizen traffic for host schedules.city.example to reach the schedules Service through an existing Gateway listener. Which Gateway API action is correct?
Select an answer to reveal the explanation.
Short Explanation
The Gateway is the curb cut; the HTTPRoute is the street sign that says “schedules.city.example goes to this Service.” Match the host, attach to the listener, and point the backend at the Service—not a bare Pod IP.
Full Explanation
Transit attaches citizen host traffic through Gateway API by creating an HTTPRoute that matches schedules.city.example, attaches to the existing Gateway listener that permits it, and targets the schedules Service as backend. The Gateway is the shared curb cut; the Route is the street sign. Matching host (and optional path) on the Route keeps routing declarative while the Service absorbs Pod churn via Endpoints or EndpointSlices. That is the standard north-south pattern for municipal host-based HTTP.
Annotating schedules Pods with a fictional gateway.host key and restarting kubelet does not implement Gateway API routing—kubelet is not the Gateway controller and Pod annotations are not HTTPRoute rules. Renaming the Gateway object to the hostname does not make DNS map to every Pod; Gateway names are API identifiers, not automatic public DNS or pod selectors. Patching CoreDNS to CNAME the host to a random Pod IP bypasses Services and Gateway attachment, couples DNS to ephemeral addresses, and fails as Pods recycle.
Exam caveat: attachment can fail if the Gateway listener’s allowedRoutes or hostname restrictions reject the HTTPRoute—Accepted status matters as much as YAML shape. TLS may terminate on the listener while the Route still only needs correct host match and backend refs.
Operational check: apply the HTTPRoute, inspect its status conditions for ParentAccepted/ResolvedRefs, confirm the schedules Service has ready endpoints, then curl -H Host: schedules.city.example against the Gateway address and verify responses from the schedules workload.