How Do Pods Communicate Across Namespaces?

Detailed Answer

By default, Kubernetes namespaces provide name isolation but not network isolation. Any Pod can communicate with any Service in any namespace using the full DNS name.

DNS for Cross-Namespace Communication

Within the same namespace, you can use the short Service name:

# From a Pod in the "backend" namespace
curl http://api-service       # Resolves to api-service.backend.svc.cluster.local

To reach a Service in a different namespace, use the full DNS format:

# From the "frontend" namespace, reach a Service in the "backend" namespace
curl http://api-service.backend.svc.cluster.local

# Shorter form (omitting the cluster domain)
curl http://api-service.backend

DNS Record Format

<service-name>.<namespace>.svc.<cluster-domain>

| Component | Example | Purpose | |---|---|---| | service-name | api-service | The Service name | | namespace | backend | The namespace containing the Service | | svc | svc | Indicates a Service record | | cluster-domain | cluster.local | The cluster's DNS domain (default) |

Example: Frontend Calling Backend

# Backend Service in "backend" namespace
apiVersion: v1
kind: Service
metadata:
  name: user-api
  namespace: backend
spec:
  selector:
    app: user-api
  ports:
    - port: 80
      targetPort: 8080
---
# Frontend Deployment in "frontend" namespace
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: myapp/web:v2
          env:
            - name: USER_API_URL
              value: "http://user-api.backend.svc.cluster.local"
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"

Restricting Cross-Namespace Traffic

By default, all cross-namespace traffic is allowed. Use Network Policies to restrict it:

# Deny all ingress from other namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: backend
spec:
  podSelector: {}    # Apply to all Pods in this namespace
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}    # Only allow from within the same namespace

To allow traffic only from specific namespaces:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-only
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: user-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: frontend
      ports:
        - port: 8080

What Cannot Cross Namespaces

| Resource | Cross-Namespace Access? | |---|---| | Service (via DNS) | Yes | | Pod-to-Pod (via IP) | Yes | | ConfigMap reference | No | | Secret reference | No | | Role/RoleBinding | No (use ClusterRole) | | PersistentVolumeClaim | No | | Ingress backend | No (Ingress routes to same namespace only) | | Gateway API HTTPRoute | Yes (with ReferenceGrant) |

ExternalName Service for Cross-Namespace Aliases

You can create a Service alias in one namespace that points to a Service in another:

apiVersion: v1
kind: Service
metadata:
  name: backend-api
  namespace: frontend
spec:
  type: ExternalName
  externalName: user-api.backend.svc.cluster.local

Now Pods in the frontend namespace can call backend-api instead of the full DNS name.

Best Practices

1. Always use full DNS names in configuration for cross-namespace communication — never hardcode Pod IPs
2. Apply Network Policies to restrict which namespaces can communicate
3. Label your namespaces for use in NetworkPolicy namespaceSelectors
4. Use ExternalName Services to create namespace-local aliases for cross-namespace dependencies
5. Document cross-namespace dependencies — they create coupling between teams