An application needs DNS that returns Pod IPs directly for custom client-side discovery instead of a single ClusterIP. Which Service configuration enables that pattern?
Select an answer to reveal the explanation.
Short Explanation
A headless Service is DNS without the virtual front desk—lookups hand you the Pod IPs so the client can pick. You get there with clusterIP: None. Handy for custom discovery; not your everyday ClusterIP load-balanced VIP.
Full Explanation
When an application needs DNS that returns Pod IPs directly for custom client-side discovery instead of a single ClusterIP, enable a headless Service by setting clusterIP to None. A headless Service is DNS without the virtual front desk—lookups hand you the Pod IPs so the client can choose among them. That pattern fits stateful sets, custom load balancers, or specialized municipal data services that implement their own discovery logic.
type LoadBalancer with externalTrafficPolicy Local alone does not make in-cluster DNS return Pod IPs instead of a virtual Service IP. type NodePort with sessionAffinity None still participates in the usual Service proxy model for ClusterIP-based access. Omitting the selector and setting type ClusterIP without clusterIP None creates a selector-less Service awaiting manual Endpoints—it is not the headless Pod-IP DNS pattern.
Exam caveat: headless Services still use selectors (or manual Endpoints) to know which Pods to publish; clusterIP: None is the defining headless marker. Operational check: kubectl get svc and confirm CLUSTER-IP shows None; from a Pod, nslookup/dig the Service DNS name and verify Pod IPs are returned; ensure application clients iterate those IPs correctly. Document headless usage in the city architecture so operators do not “repair” it by assigning a ClusterIP during an incident.