Introduction

In Kubernetes, a Service in one namespace is still reachable from Pods in another namespace, but you need the correct DNS name. The short answer is to use the service name together with the namespace, or the full cluster DNS name when you want to be explicit.

Use the Namespace in the DNS Name

Inside one namespace, a Pod can often reach a Service by just using the bare service name. That shortcut only works because Kubernetes DNS adds the current namespace to the search path.

For a Service in another namespace, include the namespace in the host name:

curl http://api.backend

In this example, api is the Service name and backend is the namespace. When cluster DNS is working normally, that is often enough.

If you want the fully qualified cluster name, use:

curl http://api.backend.svc.cluster.local

That form is more verbose, but it removes ambiguity and is useful in debugging or documentation.

Example with a Pod in Another Namespace

Suppose a Service named api exists in the backend namespace:

1apiVersion: v1
2kind: Service
3metadata:
4  name: api
5  namespace: backend
6spec:
7  selector:
8    app: api
9  ports:
10    - port: 80
11      targetPort: 8080

Now a Pod in the frontend namespace can call it through the cross-namespace DNS name:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: test-client
5  namespace: frontend
6spec:
7  containers:
8    - name: curl
9      image: curlimages/curl:8.8.0
10      command: ["sleep", "3600"]

Once the Pod is running, you can test the request:

kubectl exec -n frontend test-client -- curl http://api.backend

That request stays inside the cluster and resolves through Kubernetes DNS.

DNS Is Only Half the Story

Correct naming is necessary, but it is not the only requirement. Cross-namespace access can still fail if a NetworkPolicy blocks traffic or if the Service does not actually select healthy endpoints.

That means a working checklist usually looks like this:

• the Service name is correct
• the namespace is correct
• DNS resolves from the calling Pod
• the Service has endpoints
• network policies allow the traffic

If DNS works but the connection still fails, inspect the Service endpoints and the namespace's network policy rules next.

Debug It from Inside the Cluster

The best place to test service reachability is from a real Pod, not from your laptop. A quick debug pod gives you the same DNS search paths and network policies that your application sees.

Useful commands include:

1kubectl get svc -n backend
2kubectl get endpoints -n backend api
3kubectl exec -n frontend test-client -- nslookup api.backend
4kubectl exec -n frontend test-client -- curl http://api.backend

These commands tell you whether the failure is name resolution, endpoint selection, or network connectivity.

Common Pitfalls

The most common mistake is using only the bare service name when calling across namespaces. That usually resolves in the caller's namespace, not the target namespace.

Another issue is assuming DNS success means the application is reachable. DNS can resolve correctly while endpoints are empty or network policies still deny the connection.

People also sometimes look for special RBAC rules for service-to-service traffic. Ordinary network access between Pods and Services is not controlled by RBAC. It is controlled by networking and policy, not by API authorization.

Summary

• Access a Service in another namespace by using service.namespace or the full cluster DNS name.
• A Pod in frontend can call a Service named api in backend with http://api.backend.
• If you want the fully qualified form, use api.backend.svc.cluster.local.
• Cross-namespace traffic still depends on endpoints and network policy, not just DNS.
• Debug from inside a Pod so you see the same DNS and network behavior as the workload.