The mechanism
Cluster DNS gives Services discoverable names. Short names are resolved according to the caller’s namespace and search configuration. A name that works inside one namespace may resolve differently or fail from another. Use a sufficiently qualified name when the relationship needs to be explicit.
A successful DNS answer establishes a naming result, not application health. After resolution, traffic still crosses the Pod network, policy enforcement, Service routing and the destination process. The network plugin and cluster configuration determine important implementation details.
For ParcelOps, diagnose from the caller’s actual environment. A workstation’s resolver is not the same as a Pod’s resolver. Likewise, localhost inside a Pod refers to that Pod’s network namespace, not an arbitrary node or another Service.
Worked example
This is a conceptual name-resolution worksheet using the common cluster domain cluster.local. Clusters can configure a different domain, so verify it rather than hard-coding it into every application.
Caller namespace handbook-lab:
parcelops -> Service in the caller's namespace
parcelops.handbook-lab -> explicitly names the namespace
parcelops.handbook-lab.svc.cluster.local -> commonly used full name
localhost:8080 -> this Pod's network namespace, not the ParcelOps ServicePractice: predict, inspect, explain
Offline exercise. Draw a request from a frontend Pod in namespace web to ParcelOps in handbook-lab. Mark name resolution, source egress policy, destination ingress policy and target listener. Then compare DNS failure, connection refusal, timeout and an HTTP 500 response.
Expected observation: these symptoms point to different stages. A 500 proves that some HTTP server responded; it does not identify the correct backend without additional evidence. A timeout does not by itself prove a NetworkPolicy denial. Record the minimal observation that distinguishes each hypothesis.
Troubleshooting and trade-offs
If a short name fails across namespaces, inspect the search domain and explicit namespace before changing DNS settings. If resolution works but traffic does not, move to endpoints and packet policy. Do not edit cluster DNS or host networking for a local handbook exercise. Use saved synthetic traces when live diagnostic tooling is unavailable.
Interview practice
What does localhost mean inside a Pod?
It refers to that Pod’s network namespace. Containers in the same Pod share networking, but another Pod, Service or node is a different destination.
Why is a timeout ambiguous?
It can result from policy, routing, a silent listener, overload or other failures. Correlate DNS, endpoints, network controls and application observations.
Completion check
Build a stage-by-stage hypothesis table for DNS error, refusal, timeout and HTTP error.
Sources and version notes
Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.
- Official documentation: Dns pod service
- Official documentation: Service
- Official documentation: Network policies
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.