A developer needs a short-lived external demo of a UI on a lab cluster without an Ingress controller. Which Service choice is reasonable for that temporary access?
Select an answer to reveal the explanation.
Short Explanation
Need outsiders to poke the demo without Ingress? NodePort hangs a high port on each node’s IP—clunky for production, fine for a lab walkthrough. Just remember it’s a temporary side door, not your long-term front door.
Full Explanation
For a short-lived external demo of a UI on a lab cluster without an Ingress controller, NodePort is a reasonable temporary Service choice. NodePort publishes the Service on each node’s IP at a high port so browsers and demos can reach the app without Ingress. It is clunky for production civic sites, but fine for a lab walkthrough when you need outsiders to poke the demo quickly. Remember it is a temporary side door on node IPs, not a polished hostname on ports 80/443.
A headless Service with clusterIP None returns Pod IPs via DNS for client-side discovery; browsers do not automatically dial every Pod IP as a friendly demo URL. ExternalName pointing at the Deployment name does not make kube-proxy publish node ports—ExternalName is a DNS alias to an external hostname. ClusterIP only keeps traffic internal; laptops on office Wi-Fi do not receive cluster DNS automatically, so ClusterIP alone usually fails the “external demo” goal.
Exam caveat: NodePort ranges and firewall rules still matter in labs; know how to find the allocated port via kubectl get svc. Operational check: expose or patch the Service to NodePort, note the node port, curl http://<node-ip>:<nodePort>, and delete or revert when the demo ends so municipal lab clusters do not accumulate permanent NodePorts. Prefer Ingress for longer-lived HTTP demos when a controller exists.