An Ingress backend must target Service payments on port 8080, while Pods listen on containerPort 8080 mapped from Service port 80 via targetPort. Which port should the Ingress backend reference?
Select an answer to reveal the explanation.
Short Explanation
Ingress talks to Services, not raw container ports by imagination. Put the Service’s port (number or name) in the backend. targetPort is the Service-to-Pod hop that already happened behind the scenes.
Full Explanation
An Ingress backend must target the Service port—not a Pod IP and not a guess at containerPort alone. If Service payments exposes port 80 with targetPort mapping to containerPort 8080, the Ingress backend should reference Service port 80 (or the Service port’s name). Controllers send traffic to Services; Services forward to Pods via targetPort. Pointing Ingress at the wrong layer causes 503s and blackholes for municipal payments traffic even when Pods listen correctly on 8080.
The node’s hostPort value is not the correct Ingress backend reference for a normal Service-backed application. Ingress does not bypass Services to dial kubelet on random high ports. The etcd client port is unrelated to Ingress backend configuration and should never appear as a backend port for app traffic.
Exam caveat: backend service.port is the Service port number or name from the Service spec.ports list. Operational check: kubectl get svc payments and read PORT(S); set Ingress backend to port 80; curl through Ingress successfully; confirm Endpoints still target 8080 on Pods. Document the 80→8080 mapping so platform and app teams do not “fix” Ingress by pointing directly at 8080 when 80 is the Service port citizens’ edge rules should use.