A municipal team applies Gateway, GatewayClass, and HTTPRoute objects, but no traffic is handled at the edge. What critical dependency is still missing?
Select an answer to reveal the explanation.
Short Explanation
YAML alone is just paperwork. Gateway API objects need a real Gateway controller installed—like hiring a receptionist who actually opens the door—or nothing listens at the edge.
Full Explanation
Applying Gateway, GatewayClass, and HTTPRoute YAML without a Gateway controller leaves the municipal edge silent: Gateway API defines portable resources, but an implementation must watch those objects and program proxies, load balancers, or Envoy-like data planes. The critical missing dependency is installing that controller so listeners bind and Routes become enforced. CRDs and manifests alone are paperwork without a receptionist who opens the door.
Replacing CRI with a Gateway-only runtime is nonsensical—container runtimes create sandboxes; they are not Gateway controllers. Disabling NetworkPolicy in every namespace is unrelated; policies may filter traffic but are not required to be off for Gateways to function. Converting Services to hostNetwork Pods is not a prerequisite for Route attachment and undermines portable Service networking.
Exam caveat: GatewayClass.controllerName must match the installed implementation. Some platforms bundle controllers with the class; others require a separate Helm install. Also ensure DNS and addresses are published on Gateway status before blaming applications.
Operational check: deploy the Gateway controller, confirm its Pods are Ready, re-check Gateway and HTTPRoute status for programmed/Accepted conditions, and curl the municipal hostname through the reported Gateway address.