Public-health engineers ask whether adopting Gateway API means they can delete ClusterIP Services in front of their Pods. What should you tell them?
Select an answer to reveal the explanation.
Short Explanation
Gateway API is the street entrance; Services are still the suite numbers inside the building. Routes usually send traffic to a Service, and that ClusterIP keeps a stable frontend while Pods come and go.
Full Explanation
Public-health engineers should keep ClusterIP Services after adopting Gateway API. Gateways and Routes typically target Services as backends so north-south HTTP(S) traffic still lands on a stable virtual IP and selector-driven Endpoints while Pods scale or restart. Gateway API is the shared street entrance; Services remain the suite numbers inside the building. Deleting ClusterIPs because a listener exists breaks the usual backend pattern and in-cluster discovery that municipal apps still need east-west.
Gateway API does not replace kube-proxy or Services once a listener is Accepted—acceptance means the route attached, not that Service abstractions vanished. HTTPRoutes do not generally select Pods by UID as a Service replacement; backends are ordinarily Service references (with implementation-specific extensions still oriented around stable targets). Converting every ClusterIP to NodePort while keeping only headless Services is unnecessary and changes exposure semantics; headless Services solve Pod-IP DNS discovery, not “Gateway requires NodePort.”
Exam caveat: some advanced backend refs exist in the ecosystem, but CKA-oriented reasoning still centers on Service-backed Routes. East-west ClusterIP traffic never required Gateway API in the first place.
Operational check: after attaching an HTTPRoute, kubectl get svc,endpoints (or EndpointSlices) for the health app, confirm ready addresses, and verify both in-cluster curls to the ClusterIP/DNS name and external curls through the Gateway succeed.