From a Pod in namespace web, what DNS name reliably reaches Service my-svc in namespace my-ns?
Select an answer to reveal the explanation.
Short Explanation
Cross-namespace DNS needs the full mailing address: service, then namespace, then svc.cluster.local. So my-svc.my-ns.svc.cluster.local from the web namespace. Skip the namespace segment and you may only find a same-namespace namesake—or nothing.
Full Explanation
From a Pod in namespace web, the DNS name that reliably reaches Service my-svc in namespace my-ns is my-svc.my-ns.svc.cluster.local—the standard cross-namespace Service FQDN form. The segments are service name, then namespace, then svc.cluster.local. Municipal microservices that call shared platform services across namespaces should use this FQDN (or at least my-svc.my-ns) so resolution does not depend on the caller’s local search path guessing the wrong namespace.
my-svc.svc.cluster.local without a namespace segment does not identify which namespace owns the Service. my-ns.my-svc.cluster.local incorrectly places the namespace before the Service name relative to the Kubernetes DNS convention. my-svc.cluster.local is incomplete, and it is false that namespaces are ignored for Services—Services are namespaced objects and DNS reflects that.
Exam caveat: short names like my-svc work inside the same namespace via search domains; cross-namespace calls need the namespace segment. On CKAD, writing the FQDN in the wrong order is a common trap. Operational check: from a Pod in web, run nslookup my-svc.my-ns.svc.cluster.local and curl the Service port; deliberately try the reversed order and observe failure or unexpected resolution. Put the correct FQDN in city ConfigMaps and application examples for cross-namespace permits, billing, and shared services so developers copy a known-good string.