A Service is ClusterIP and you need a brief external test on node IPs without recreating the object from scratch. What change accomplishes that exposure style?
Select an answer to reveal the explanation.
Short Explanation
You can promote a ClusterIP Service to NodePort with a patch or edit—same object, new exposure style for that short external test. You’re flipping the type, not inventing a fake headless annotation or changing apiVersion theater.
Full Explanation
If a Service is ClusterIP and you need a brief external test on node IPs without recreating the object from scratch, patch or edit the Service type from ClusterIP to NodePort. Changing spec.type is the supported way to evolve exposure style on the existing object and allocates node ports for temporary access during lab demos or break-glass checks for municipal apps.
Annotating the Service with service.kubernetes.io/headless=true only does not create NodePort exposure and misunderstands headless semantics. Setting selector to empty so Endpoints supposedly publish node IPs automatically does not convert ClusterIP into NodePort access for browsers. Changing the Service apiVersion is unrelated to exposing NodePort fields and will not accomplish the test.
Exam caveat: flipping type on a shared production Service can surprise other consumers; prefer ephemeral test Services in real city clusters when possible. Operational check: kubectl patch svc <name> -p '{"spec":{"type":"NodePort"}}' or kubectl edit, read the assigned node port from kubectl get svc, curl http://<node-ip>:<nodePort>, then patch back to ClusterIP when finished so the Service does not remain broadly exposed on node ports.