Introduction

In OpenShift, a service in another namespace is reachable the same way as any other in-cluster service if networking policy allows it. The namespace itself does not require a "network join" just for DNS resolution. The real question is whether cluster isolation rules allow traffic, and if not, whether you want to permit it directly or expose a narrower entry point.

Core Sections

Start With the Service DNS Name

Kubernetes and OpenShift service discovery includes the namespace in the DNS name. A pod in namespace client can call a service in namespace payments with a host like:

http://billing-api.payments.svc.cluster.local:8080

A deployment that uses that service might look like:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: report-worker
5  namespace: client
6spec:
7  replicas: 1
8  selector:
9    matchLabels:
10      app: report-worker
11  template:
12    metadata:
13      labels:
14        app: report-worker
15    spec:
16      containers:
17        - name: worker
18          image: registry.example.com/report-worker:latest
19          env:
20            - name: BILLING_API_URL
21              value: "http://billing-api.payments.svc.cluster.local:8080"

If your cluster allows cross-namespace traffic, this is enough.

DNS Resolution Does Not Guarantee Connectivity

A common mistake is assuming that because the service name resolves, access is allowed. In isolated OpenShift environments, DNS may succeed while the TCP connection is still blocked by:

• 'NetworkPolicy'
• namespace isolation rules
• custom CNI restrictions

That is why you should test both resolution and connectivity:

oc run net-debug -n client --image=registry.access.redhat.com/ubi9/ubi-minimal --restart=Never -it -- bash
getent hosts billing-api.payments.svc.cluster.local
curl -v http://billing-api.payments.svc.cluster.local:8080/health

Those are different checks with different failure modes.

Allow Direct Access With a Targeted NetworkPolicy

If direct pod-to-service access is the goal, a targeted policy is usually better than broad namespace-level relaxation.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-client-namespace
5  namespace: payments
6spec:
7  podSelector:
8    matchLabels:
9      app: billing-api
10  policyTypes:
11    - Ingress
12  ingress:
13    - from:
14        - namespaceSelector:
15            matchLabels:
16              kubernetes.io/metadata.name: client
17      ports:
18        - protocol: TCP
19          port: 8080

This keeps access narrow and explicit.

Use a Route When You Want a Controlled HTTP Entry Point

If you do not want direct pod-network access, expose the service through a Route instead:

1apiVersion: route.openshift.io/v1
2kind: Route
3metadata:
4  name: billing-api
5  namespace: payments
6spec:
7  to:
8    kind: Service
9    name: billing-api
10  port:
11    targetPort: 8080
12  tls:
13    termination: edge

The consuming service then calls the route host rather than the internal service DNS name.

This is often better when:

1. the protocol is HTTP or HTTPS
2. you want TLS termination
3. you want a reviewed and explicit boundary between teams

Choose Based on the Trust Boundary

Use internal service DNS when:

• traffic should stay private inside the cluster
• the cluster permits the namespace-to-namespace path
• you do not need router features

Use a Route or gateway when:

• pod-network isolation should stay in place
• consumers should access only an approved HTTP endpoint
• external hostname, TLS, or ingress policy is part of the design

This is more about security and platform policy than DNS mechanics.

Be Careful With Service Accounts and RBAC Assumptions

RBAC controls access to the Kubernetes API. It does not automatically control normal TCP traffic between pods. Teams sometimes try to solve connectivity with service-account permissions when the actual issue is network policy or route exposure.

Keep the layers separate:

• API authorization is RBAC
• service-to-service network reachability is networking policy

Practical Troubleshooting Flow

When a service in another namespace is unreachable:

1. confirm the service name and port
2. test DNS resolution from the source namespace
3. test a direct connection
4. inspect NetworkPolicy in the target namespace
5. decide whether direct access or a Route is the intended pattern

That sequence keeps troubleshooting grounded in the correct layer.

Common Pitfalls

• Assuming service DNS resolution means the connection will also be allowed.
• Opening access broadly when a narrow NetworkPolicy would solve the problem.
• Exposing a Route externally when only private in-cluster access was required.
• Trying to solve normal service connectivity with RBAC changes.
• Forgetting that OpenShift clusters may have tenant isolation policies beyond default Kubernetes behavior.

Summary

• A service in another namespace is usually accessed by its full DNS name if networking allows it.
• DNS resolution and network reachability are separate concerns.
• Use targeted NetworkPolicy rules for private direct access when needed.
• Use an OpenShift Route when you want an explicit HTTP or HTTPS entry point instead of raw pod-network connectivity.
• Pick the access pattern based on trust boundaries, not just what is technically possible.