Introduction

Connecting an app in one Kubernetes namespace to MongoDB in another namespace is a standard cluster networking scenario. Namespaces isolate resources logically, but service DNS and cluster networking allow cross-namespace traffic by default unless policies restrict it. Most failures come from wrong service address, missing endpoints, or blocked network policy.

Use Namespace-Aware Service DNS

A pod in namespace app cannot reliably reach a service in namespace data by short name alone. Use fully qualified DNS name.

Format:

service.namespace.svc.cluster.local

Example connection host for MongoDB service named mongo in namespace data:

mongo.data.svc.cluster.local

Deployment example:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5  namespace: app
6spec:
7  replicas: 1
8  selector:
9    matchLabels:
10      app: api
11  template:
12    metadata:
13      labels:
14        app: api
15    spec:
16      containers:
17      - name: api
18        image: ghcr.io/example/api:latest
19        env:
20        - name: MONGO_URI
21          value: mongodb://mongo.data.svc.cluster.local:27017/orders

If this hostname is wrong, app cannot connect even if MongoDB pod is healthy.

Verify MongoDB Service and Endpoints

A running pod is not enough. Service selector must match pod labels so endpoints are populated.

1apiVersion: v1
2kind: Service
3metadata:
4  name: mongo
5  namespace: data
6spec:
7  selector:
8    app: mongo
9  ports:
10  - port: 27017
11    targetPort: 27017

Check endpoints:

kubectl -n data get endpoints mongo

If endpoint list is empty, selector mismatch or pod readiness is likely the cause.

Credentials and Secrets Across Namespaces

Secrets are namespace-scoped. A pod in app cannot directly reference secret objects in data namespace. Duplicate or sync credentials into consuming namespace securely.

1apiVersion: v1
2kind: Secret
3metadata:
4  name: mongo-auth
5  namespace: app
6type: Opaque
7stringData:
8  username: appuser
9  password: strong-password

Build URI at runtime from secret values rather than hardcoding credentials in manifests.

NetworkPolicy and Cross-Namespace Traffic

If network policies are enabled, default deny rules may block cross-namespace connections. Add explicit ingress allow policy in Mongo namespace.

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

Make sure namespace labels used by selectors actually exist.

Runtime Diagnostics from App Namespace

Test from inside app pod, not from your laptop, because in-cluster DNS and policy are what matter.

kubectl -n app exec deploy/api -- nslookup mongo.data.svc.cluster.local
kubectl -n app exec deploy/api -- sh -c 'nc -zv mongo.data.svc.cluster.local 27017'

Then inspect Mongo logs for auth errors versus network errors.

kubectl -n data logs deploy/mongo

This helps distinguish DNS failure, TCP denial, and authentication mismatch.

StatefulSet and Headless Service Notes

If MongoDB runs in StatefulSet with headless service, clients may target individual pod DNS names or replica set URI. In that case ensure your app driver config matches replica set topology and namespace-qualified hostnames.

For single-instance service access, normal ClusterIP service is simpler and usually preferred.

Service Account and DNS Policy Checks

If your workload uses custom DNS policy or hardened runtime settings, verify pod DNS resolution still uses cluster DNS. Also ensure service account and admission policies are not mutating network settings unexpectedly between environments.

Common Pitfalls

• Using short service name instead of namespace-qualified DNS.
• Assuming pod health guarantees service endpoint readiness.
• Referencing secrets from another namespace directly.
• Forgetting network policies that block cross-namespace ingress.
• Debugging from local machine instead of in-cluster pod context.

Summary

• Cross-namespace MongoDB access works when service DNS and policy are configured correctly.
• Use service.namespace.svc.cluster.local for deterministic routing.
• Confirm service endpoints, credentials, and network policy together.
• Test connectivity from app pod namespace to isolate real cluster behavior.
• Treat namespace-scoped secret and policy rules as first-class architecture constraints.