Cross-namespace communication in Kubernetes - Step-by-Step Execution

Process Flow - Cross-namespace communication

Pod in Namespace A

↓

Send request to Service in Namespace B

↓

Kubernetes DNS resolves service.ns-b.svc.cluster.local

↓

Request routed to Service in Namespace B

↓

Service forwards to Pod(s) in Namespace B

↓

Pod in Namespace B processes request and responds

A pod in one namespace sends a request to a service in another namespace using the full DNS name, which Kubernetes resolves and routes to the target pod.

Execution Sample

Kubernetes

kubectl run client --image=busybox -n ns-a -- sleep 3600
kubectl exec -n ns-a client -- wget -qO- http://service.ns-b.svc.cluster.local

A pod in namespace 'ns-a' tries to access a service in namespace 'ns-b' using the full DNS name.

Process Table

Step	Action	Command/Request	Result/Output
1	Create pod in ns-a	kubectl run client --image=busybox -n ns-a -- sleep 3600	Pod 'client' running in namespace 'ns-a'
2	Pod in ns-a sends HTTP request	wget -qO- http://service.ns-b.svc.cluster.local	DNS resolves to service IP in ns-b
3	Request routed to service in ns-b	Service forwards request	Request reaches pod(s) behind service in ns-b
4	Pod in ns-b processes request	Pod responds	HTTP response returned to pod in ns-a
5	Pod in ns-a receives response	wget output	<HTML or service response content>
6	Exit	Request complete	Cross-namespace communication successful

💡 Request completes successfully after routing through Kubernetes DNS and service in another namespace

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Pod in ns-a	Not running	Running	Running	Running	Running
DNS resolution	Not done	Resolved to service IP	Resolved	Resolved	Resolved
Request state	None	Sent	Routed	Processed	Response received

Key Moments - 2 Insights

Why do we need to use the full DNS name including the namespace to reach a service in another namespace?

Because Kubernetes DNS resolves services within the same namespace by default, to reach a service in a different namespace you must specify the full DNS name like service.namespace.svc.cluster.local as shown in step 2 of the execution_table.

Can a pod in one namespace access a pod directly in another namespace without a service?

No, direct pod-to-pod communication across namespaces is not recommended and usually blocked; communication should go through a service as shown in steps 3 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the DNS resolution happen?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'DNS resolves to service IP' note in the Result/Output column at step 2.

According to variable_tracker, what is the state of the request after step 3?

A Routed

B Sent

C None

D Processed

💡 Hint

Look at the 'Request state' row under 'After Step 3' column.

If the pod in ns-a used just 'http://service' without namespace, what would happen?

A Request would reach service in ns-b

B Request would reach a service in ns-a if exists

C Request would fail DNS resolution

D Request would be routed to all namespaces

💡 Hint

Kubernetes DNS resolves service names within the same namespace by default, see explanation in key_moments.

Concept Snapshot

Cross-namespace communication in Kubernetes:
- Pods communicate across namespaces via Services
- Use full DNS name: service.namespace.svc.cluster.local
- Kubernetes DNS resolves and routes requests
- Direct pod-to-pod cross-namespace access is discouraged
- Services provide stable endpoints for cross-namespace access

Full Transcript

In Kubernetes, pods in one namespace can communicate with services in another namespace by using the full DNS name of the service, which includes the service name, namespace, and cluster domain. The flow starts with a pod in namespace A sending a request to a service in namespace B. Kubernetes DNS resolves the full service name to the service's cluster IP in namespace B. The request is routed through the service to the pods behind it in namespace B. The pods process the request and send back a response. This method ensures proper routing and isolation between namespaces. Direct pod-to-pod communication across namespaces is not recommended and usually blocked. Using services and full DNS names is the standard way to enable cross-namespace communication.

Practice

1. What is the main purpose of namespaces in Kubernetes?

easy

A. To group and isolate resources within the cluster

B. To increase the number of nodes in the cluster

C. To speed up container startup time

D. To automatically update container images

Solution

1. Step 1: Understand namespaces role

   Namespaces help organize and isolate resources like pods and services inside a Kubernetes cluster.

2. Step 2: Compare options

   Options B, C, and D describe unrelated cluster features, not namespaces.

3. Final Answer:

   To group and isolate resources within the cluster -> Option A

4. Quick Check:

   Namespaces = resource grouping and isolation [OK]

Hint: Namespaces isolate resources logically inside the cluster [OK]

Common Mistakes:

• Confusing namespaces with nodes
• Thinking namespaces speed up containers
• Assuming namespaces auto-update images

2. Which DNS name format is correct to access a service named webapp in namespace prod from another namespace?

easy

A. svc.webapp.prod.cluster.local

B. prod.webapp.svc.cluster.local

C. webapp.prod.svc.cluster.local

D. webapp.svc.prod.cluster.local

Solution

1. Step 1: Recall Kubernetes DNS format

   The full DNS name for a service is service.namespace.svc.cluster.local.

2. Step 2: Match the format to the service and namespace

   For service webapp in namespace prod, the correct format is webapp.prod.svc.cluster.local.

3. Final Answer:

   webapp.prod.svc.cluster.local -> Option C

4. Quick Check:

   DNS = service.namespace.svc.cluster.local [OK]

Hint: Use service.namespace.svc.cluster.local for cross-namespace access [OK]

Common Mistakes:

• Swapping service and namespace order
• Omitting 'svc' in DNS name
• Using incorrect domain suffix

3. Given this command run in namespace dev:

kubectl exec -n dev pod1 -- curl http://api.prod.svc.cluster.local

What is the expected result if api service exists in prod namespace and network policies allow cross-namespace traffic?

medium

A. The curl command fails with DNS resolution error

B. The pod1 container crashes immediately

C. The curl command times out due to network policy blocking

D. The curl command successfully connects to the api service

Solution

1. Step 1: Understand DNS and network policy

   The DNS name api.prod.svc.cluster.local correctly targets the service in the prod namespace.

2. Step 2: Check network policy effect

   Since network policies allow cross-namespace traffic, the connection is permitted.

3. Final Answer:

   The curl command successfully connects to the api service -> Option D

4. Quick Check:

   Allowed network + correct DNS = successful connection [OK]

Hint: Correct DNS + allowed network = successful cross-namespace call [OK]

Common Mistakes:

• Assuming DNS fails without explicit config
• Ignoring network policy restrictions
• Expecting pod crash on curl failure

4. You try to access db.prod.svc.cluster.local from namespace dev but get a timeout. What is the most likely cause?

medium

A. The service db does not exist in prod

B. Network policies block traffic between dev and prod

C. The pod in dev has no internet access

D. The DNS name is incorrectly formatted

Solution

1. Step 1: Verify service existence

   If the service did not exist, DNS would fail, not timeout.

2. Step 2: Analyze network policy impact

   Timeout usually means packets are blocked by network policies preventing cross-namespace communication.

3. Final Answer:

   Network policies block traffic between dev and prod -> Option B

4. Quick Check:

   Timeout = network block, not DNS error [OK]

Hint: Timeout often means network policy blocks traffic [OK]

Common Mistakes:

• Confusing timeout with DNS failure
• Assuming pod internet access affects cluster DNS
• Misreading DNS format as cause

5. You want to allow a pod in namespace frontend to access a service backend in namespace api. Which steps are needed to enable this cross-namespace communication?

hard

A. Use the full DNS name backend.api.svc.cluster.local and configure network policies to allow traffic from frontend to api

B. Create a service account in frontend and bind it to api namespace

C. Expose the backend service as NodePort and access it via node IP

D. Deploy the backend service in frontend namespace instead

Solution

1. Step 1: Use correct DNS name for cross-namespace access

   Accessing a service in another namespace requires the full DNS name: backend.api.svc.cluster.local.

2. Step 2: Configure network policies

   Network policies must allow traffic from pods in frontend namespace to api namespace services.

3. Final Answer:

   Use the full DNS name backend.api.svc.cluster.local and configure network policies to allow traffic from frontend to api -> Option A

4. Quick Check:

   DNS + network policy = cross-namespace communication [OK]

Hint: Full DNS + network policy allow = cross-namespace access [OK]

Common Mistakes:

• Confusing service accounts with network access
• Using NodePort unnecessarily
• Moving services instead of configuring access