Why define a named container port (for example name: http) and set the Service targetPort: http instead of only numeric ports?
Select an answer to reveal the explanation.
Short Explanation
Names are sticky labels on the door while room numbers can move. If the container still calls the port http, the Service can keep targeting http even after you renumber 8080 to 9090. Fewer brittle YAML chases.
Full Explanation
Defining a named container port (for example name: http) and setting the Service targetPort: http keeps the Service valid when the container’s numeric port changes but the name stays the same. Names are sticky labels on the door while room numbers can move. If the container still calls the port http, the Service can keep targeting http even after you renumber 8080 to 9090, which reduces brittle edits across municipal manifests, Ingress backends, and docs.
Named ports do not disable Endpoints so only Ingress can route traffic. Named targetPort does not force the Service type to become LoadBalancer. Named ports are not required exclusively for ClusterIP and forbidden on NodePort—they are a portable targeting convenience across Service types.
Exam caveat: the string name on the container port and the Service targetPort must match exactly; typos recreate the blackhole problem with names instead of numbers. Operational check: define container port name http, set Service targetPort to http, change the numeric container port, confirm Endpoints still map correctly and curls succeed without editing the Service targetPort field. Prefer named ports in city platform Helm/Kustomize templates for both HTTP and metrics ports.