Cross-namespace communication in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the namespace when accessing a service in another namespace.

Kubernetes

kubectl get svc my-service -n [1]

Drag options to blanks, or click blank then click option'

Adefault

Bproduction

Ckube-system

Ddev

Attempts:

3 left

💡 Hint

Common Mistakes

Forgetting to specify the namespace, causing errors or looking in the wrong namespace.

Using -n production tells kubectl to look for the service in the 'production' namespace.

2fill in blank

medium

Complete the service URL to access a service named 'api' in the 'backend' namespace from another namespace.

Kubernetes

http://api.[1].svc.cluster.local

Drag options to blanks, or click blank then click option'

Abackend

Bfrontend

Cdefault

Dkube-system

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong namespace in the URL, causing DNS resolution failure.

The full DNS name includes the service name, namespace, and cluster domain. Here, the namespace is 'backend'.

3fill in blank

hard

Fix the error in the pod spec to allow cross-namespace service access by completing the service name with namespace.

Kubernetes

        - name: API_URL
          value: "http://api.[1].svc.cluster.local"

Drag options to blanks, or click blank then click option'

Adefault

Bfrontend

Cbackend

Dkube-system

Attempts:

3 left

💡 Hint

Common Mistakes

Omitting the namespace or using the wrong namespace in the URL.

Specifying the correct namespace 'backend' in the service URL allows the pod to reach the service across namespaces.

4fill in blank

hard

Fill both blanks to create a NetworkPolicy that allows ingress traffic from pods in the 'frontend' namespace to pods in the 'backend' namespace.

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          [1]: [2]

Drag options to blanks, or click blank then click option'

Aname

Bfrontend

Capp

Dbackend

Attempts:

3 left

💡 Hint

Common Mistakes

Using pod labels instead of namespace labels, or wrong label keys/values.

The NetworkPolicy uses namespaceSelector with label name: frontend to allow traffic from the 'frontend' namespace.

5fill in blank

hard

Fill all three blanks to create a RoleBinding that grants the 'view' role to the 'dev-team' group in the 'testing' namespace.

Kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view-binding
  namespace: [1]
subjects:
- kind: Group
  name: [2]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: [3]
  apiGroup: rbac.authorization.k8s.io

Drag options to blanks, or click blank then click option'

Atesting

Bdev-team

Cview

Dadmin

Attempts:

3 left

💡 Hint

Common Mistakes

Using cluster roles instead of roles, or wrong namespace or group names.

This RoleBinding applies in the 'testing' namespace, grants the 'view' role to the 'dev-team' group.

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