Cross-namespace communication in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does Kubernetes enable communication between services in different namespaces?

In Kubernetes, services are usually isolated within namespaces. Which method allows a pod in one namespace to reach a service in another namespace?

A Services in different namespaces cannot communicate directly; you must merge namespaces.

B Use the full DNS name of the service including the target namespace, like <code>service-name.namespace.svc.cluster.local</code>.

C Use the service name alone without namespace; Kubernetes automatically resolves cross-namespace services.

D Create a NodePort service and access it via the node IP and port.

💡 Hint

Think about how Kubernetes DNS resolves service names across namespaces.

Kubernetes DNS allows cross-namespace communication by using the full DNS name including the namespace. This is service-name.namespace.svc.cluster.local. Using only the service name works only within the same namespace.

💻 Command Output

intermediate

What is the output of this command querying a service in another namespace?

You run the following command inside a pod in namespace dev to check connectivity to a service api in namespace prod:

nslookup api.prod.svc.cluster.local

What output do you expect?

A A DNS response with the IP address of the <code>api</code> service in <code>prod</code> namespace.

B An error saying <code>api.prod.svc.cluster.local</code> not found.

C A DNS response with the IP address of a service named <code>api</code> in the <code>dev</code> namespace.

D A timeout error because cross-namespace DNS queries are blocked.

💡 Hint

Remember how Kubernetes DNS resolves fully qualified service names.

The command queries the fully qualified domain name of the service api in the prod namespace. Kubernetes DNS resolves this correctly and returns the service IP.

❓ Configuration

advanced

Which NetworkPolicy allows pods in namespace 'frontend' to access pods in namespace 'backend' on port 8080?

You want to restrict network access so only pods in the frontend namespace can connect to pods in the backend namespace on TCP port 8080. Which NetworkPolicy YAML snippet correctly implements this?

A

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 8080

B

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: frontend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 8080

C

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - protocol: TCP
      port: 8080

D

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

💡 Hint

NetworkPolicies are defined in the target namespace and use namespaceSelector to allow traffic from other namespaces.

The NetworkPolicy must be created in the backend namespace to control ingress to backend pods. It allows ingress from pods in namespaces labeled name: frontend on TCP port 8080.

❓ Troubleshoot

advanced

Why does a pod in namespace 'test' fail to reach a service in namespace 'prod' using only the service name?

A pod in the test namespace tries to connect to a service named db in the prod namespace by using the hostname db. The connection fails. What is the most likely reason?

A The pod's network policy explicitly denies all outbound traffic.

B The service <code>db</code> in <code>prod</code> namespace is not running any pods.

C Kubernetes blocks all cross-namespace service communication by default.

D The pod is using the short service name <code>db</code> which resolves only within its own namespace, so it cannot find the service in <code>prod</code> namespace.

💡 Hint

Think about how DNS resolves service names inside pods.

Using only the service name db resolves to a service in the pod's own namespace (test). To reach a service in another namespace, the full DNS name including namespace must be used.

✅ Best Practice

expert

What is the recommended way to securely enable cross-namespace communication between microservices?

You manage multiple microservices deployed in different namespaces. You want to enable secure, controlled communication between them. Which approach is best practice?

A Use Kubernetes NetworkPolicies to restrict traffic and service accounts with RBAC for authentication, combined with mutual TLS via a service mesh like Istio.

B Open all namespaces to unrestricted communication by disabling NetworkPolicies and use plain HTTP between services.

C Manually configure firewall rules on each node to allow traffic between namespaces and use basic authentication in services.

D Deploy all microservices in the same namespace to avoid cross-namespace communication issues.

💡 Hint

Consider security, scalability, and maintainability in multi-namespace environments.

Combining NetworkPolicies for network-level restrictions, RBAC for access control, and mutual TLS via a service mesh provides a robust, secure, and manageable 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