Introduction

In Kubernetes, service discovery depends on DNS names that include both service and namespace context. Many issues that look like network failures are actually naming mismatches. Knowing how to retrieve and construct the full service name correctly makes debugging and cross-namespace communication much easier.

What the Full Service Name Looks Like

A Kubernetes service DNS name normally follows this pattern:

service-name.namespace.svc.cluster.local

Parts:

• service-name: the metadata name of the Service object.
• namespace: namespace where the service lives.
• svc: fixed DNS subdomain for services.
• cluster.local: cluster domain default, configurable in some clusters.

Inside the same namespace, many clients can use just service-name. For cross-namespace calls, use at least service-name.namespace.

Retrieve Service Name and Namespace with kubectl

Start by fetching canonical metadata from the API.

kubectl get svc my-api -n payments -o jsonpath='{.metadata.name}{"\n"}{.metadata.namespace}{"\n"}'

Construct full DNS manually:

echo "my-api.payments.svc.cluster.local"

You can also print both in one command:

kubectl get svc my-api -n payments -o jsonpath='{.metadata.name}.{.metadata.namespace}.svc.cluster.local{"\n"}'

Confirm Resolution from a Pod

The best validation is DNS lookup from a running pod in the cluster.

kubectl run dns-test --rm -it --image=busybox:1.36 --restart=Never -- sh

Inside the shell:

nslookup my-api.payments.svc.cluster.local
wget -qO- http://my-api.payments.svc.cluster.local:8080/health

If nslookup fails, investigate DNS and namespace assumptions before checking application code.

Reading Full Name Programmatically

In automation scripts, build the FQDN from API fields instead of hardcoding.

Python example:

1from kubernetes import client, config
2
3config.load_kube_config()
4v1 = client.CoreV1Api()
5svc = v1.read_namespaced_service(name="my-api", namespace="payments")
6
7service_fqdn = f"{svc.metadata.name}.{svc.metadata.namespace}.svc.cluster.local"
8print(service_fqdn)

This keeps scripts correct even when service names or namespaces are environment-specific.

Cluster Domain May Differ

Although many clusters use cluster.local, some environments customize this domain. If you assume the default blindly, DNS calls can fail.

You can inspect CoreDNS configuration:

kubectl -n kube-system get configmap coredns -o yaml

Look for plugin settings showing the active cluster domain. If domain differs, append that domain in your constructed FQDN.

Short Names Versus Full Names

Use short names when scope is obvious:

• Same namespace: my-api
• Cross namespace: my-api.payments

Use full name when:

• Debugging ambiguous DNS behavior.
• Communicating across multiple namespaces.
• Writing scripts where explicitness matters more than brevity.

Being explicit avoids accidental namespace coupling.

Discovering Service Context from Inside a Pod

Applications can read their own namespace at runtime and compose service targets dynamically. This is useful in multi-tenant deployments where namespace is not hardcoded.

1env:
2  - name: POD_NAMESPACE
3    valueFrom:
4      fieldRef:
5        fieldPath: metadata.namespace

With this value, app code can construct service-name.$POD_NAMESPACE.svc.cluster.local when same-namespace service routing is required. It also helps when the same container image is promoted through multiple namespaces without rebuilds.

Debugging Checklist

When full name resolution fails:

1. Verify service exists in expected namespace.
2. Verify endpoint objects have backing pod IPs.
3. Verify pod DNS policy is standard cluster DNS.
4. Verify cluster domain assumption.
5. Test from in-cluster shell.

Endpoint check command:

kubectl get endpoints my-api -n payments -o wide

No endpoints usually indicates selector or pod readiness issues, not DNS naming problems.

Common Pitfalls

• Assuming service short name works across namespaces. Fix by using service.namespace or full FQDN.
• Hardcoding default namespace assumptions. Fix by reading metadata namespace explicitly.
• Forgetting custom cluster domain setups. Fix by confirming DNS domain in CoreDNS config.
• Debugging app code before checking endpoints. Fix by validating service and endpoint state first.
• Building names manually with typos in scripts. Fix by generating FQDN from API metadata fields.

Summary

• Full service DNS is usually service.namespace.svc.cluster.local.
• Fetch name and namespace from Kubernetes API to avoid mistakes.
• Validate DNS resolution from within a cluster pod.
• Confirm cluster domain if default assumptions fail.
• Combine service DNS checks with endpoint checks for reliable troubleshooting.