Introduction

In Kubernetes, services are cluster-scoped network endpoints even though their names are namespaced. That means a pod in one namespace can access a service in another namespace as long as DNS, routing, and network policy allow it. The main trick is using the correct service DNS name instead of assuming short names resolve across namespaces automatically.

Use the Service Name with the Target Namespace

Within the same namespace, a pod can often reach a service by short name alone. Across namespaces, you should include the namespace in the DNS name.

database-service.backend

That usually works because Kubernetes DNS expands it to the fully qualified service name.

If you want the explicit fully qualified form, use:

database-service.backend.svc.cluster.local

Both point to the service named database-service in the backend namespace.

Test It from a Pod

A quick way to verify cross-namespace service discovery is running a temporary pod and resolving the name.

1kubectl run test-client \
2  --rm -it \
3  --image=busybox:1.36 \
4  --restart=Never \
5  -- nslookup database-service.backend.svc.cluster.local

If DNS is working, the service name should resolve to the ClusterIP. Then test the actual port with a tool appropriate to the image, such as wget, nc, or curl.

1kubectl run curl-test \
2  --rm -it \
3  --image=curlimages/curl:8.7.1 \
4  --restart=Never \
5  -- curl http://database-service.backend:5432

The exact protocol depends on the service, but the service naming pattern stays the same.

Understand What Does Not Cross Namespaces Automatically

Two common assumptions are wrong:

• short service names do not automatically resolve across namespaces
• environment variables for services are not a reliable cross-namespace discovery mechanism

DNS is the standard solution here. It is explicit and works across namespaces without inventing custom discovery logic.

Network Policies Can Still Block Access

Name resolution alone does not guarantee connectivity. If network policies are enabled, the destination namespace may block ingress from the source namespace.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-frontend-to-backend
5  namespace: backend
6spec:
7  podSelector:
8    matchLabels:
9      app: database
10  policyTypes:
11    - Ingress
12  ingress:
13    - from:
14        - namespaceSelector:
15            matchLabels:
16              kubernetes.io/metadata.name: frontend

This kind of policy is often the real reason a cross-namespace service "does not work" even though DNS resolution succeeds.

Services Do Not Need to Be External for This

You do not need NodePort, LoadBalancer, or an Ingress just to connect between namespaces inside the cluster. A normal ClusterIP service is exactly the right service type for in-cluster, cross-namespace traffic.

That is a common design mistake. Internal service-to-service traffic should stay internal unless there is a real external access requirement.

Prefer Explicit Hostnames in Config

If an application in namespace frontend depends on a service in namespace backend, write that dependency explicitly in configuration.

env:
  - name: DATABASE_HOST
    value: database-service.backend.svc.cluster.local

That makes the dependency visible and avoids accidental ambiguity if another namespace later defines a service with the same short name.

Common Pitfalls

• Using only the short service name and expecting it to resolve across namespaces.
• Assuming a DNS success means network policy is not involved.
• Exposing an internal dependency through NodePort or LoadBalancer when ClusterIP would be correct.
• Relying on service environment variables instead of standard DNS-based discovery.
• Forgetting that the destination service must still listen on the expected port and protocol after DNS resolution succeeds.

Summary

• Access a service in another namespace by using service.namespace or the full cluster DNS name.
• Cross-namespace service access works with ordinary ClusterIP services.
• Test both DNS resolution and actual connectivity from a pod.
• Check network policies if name resolution works but traffic still fails.
• Prefer explicit namespace-qualified service names in application configuration.