Service discovery via DNS in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does Kubernetes DNS service discovery work?

In Kubernetes, how does the DNS service discovery mechanism help pods find other services?

A Pods use DNS names that resolve to service cluster IPs, allowing communication without hardcoding IPs.

B Pods communicate only via static IP addresses assigned manually to each pod.

C Pods use environment variables only to discover other services, DNS is not involved.

D Pods must use external DNS servers to resolve service names outside the cluster.

💡 Hint

Think about how pods avoid using fixed IPs and still find services dynamically.

Kubernetes creates DNS entries for services that resolve to their cluster IPs. Pods use these DNS names to communicate without needing fixed IPs.

💻 Command Output

intermediate

Output of DNS lookup inside a pod

What is the output of the following command run inside a pod in Kubernetes?

nslookup my-service.default.svc.cluster.local

A nslookup: can't resolve 'my-service.default.svc.cluster.local'

B

Name: my-service.default.svc.cluster.local
Address: 10.96.0.1

C

Name: my-service
Address: 192.168.1.1

D Error: command not found

💡 Hint

Consider the default cluster IP range and DNS naming conventions.

The DNS name resolves to the cluster IP of the service, typically in the 10.96.0.0/12 range by default.

❓ Configuration

advanced

Correct DNS configuration for a headless service

Which YAML snippet correctly defines a headless service to enable DNS-based service discovery of individual pods?

A

apiVersion: v1
kind: Service
metadata:
  name: my-headless
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80

B

apiVersion: v1
kind: Service
metadata:
  name: my-headless
spec:
  clusterIP: 10.96.0.10
  selector:
    app: myapp
  ports:
  - port: 80

C

apiVersion: v1
kind: Service
metadata:
  name: my-headless
spec:
  clusterIP: None
  selector:
    app: myapp
  ports:
  - port: 80

D

apiVersion: v1
kind: Service
metadata:
  name: my-headless
spec:
  externalName: myapp.example.com
  ports:
  - port: 80

💡 Hint

Headless services have no cluster IP to allow direct pod DNS entries.

Setting clusterIP to None creates a headless service, enabling DNS to return pod IPs directly for service discovery.

❓ Troubleshoot

advanced

Troubleshooting DNS resolution failure in a pod

A pod cannot resolve the DNS name of a service inside the cluster. Which is the most likely cause?

A The pod's container image is missing the nslookup tool.

B The pod is using hostNetwork: true.

C The service has no ports defined in its spec.

D The CoreDNS pods are not running or have crashed.

💡 Hint

DNS resolution depends on a running DNS server inside the cluster.

If CoreDNS pods are down, DNS queries inside the cluster fail, causing resolution errors.

🔀 Workflow

expert

Order the steps to verify DNS-based service discovery in Kubernetes

Put these steps in the correct order to verify DNS-based service discovery inside a Kubernetes cluster.

A 2,4,1,3

B 2,1,4,3

C 1,2,4,3

D 4,2,1,3

💡 Hint

Start by checking cluster components, then run tests inside pods.

First verify the service exists, then confirm DNS server health, next run a pod with DNS tools, and finally query the service DNS name.

Practice

1. What does Kubernetes use to help applications find each other without hardcoding IP addresses?

easy

A. Manual IP configuration

B. DNS-based service discovery

C. Static routing tables

D. Load balancer IPs only

Solution

1. Step 1: Understand service discovery basics

   Kubernetes provides a way for apps to find each other by name instead of IP, which can change.

2. Step 2: Identify the mechanism Kubernetes uses

   Kubernetes automatically creates DNS entries for services, enabling DNS-based discovery.

3. Final Answer:

   DNS-based service discovery -> Option B

4. Quick Check:

   Service discovery = DNS-based [OK]

Hint: Kubernetes uses DNS names, not fixed IPs, for service discovery [OK]

Common Mistakes:

• Thinking IPs are fixed and manually configured
• Confusing load balancers with service discovery
• Assuming static routing is used

2. Which of the following is the correct DNS name format to access a Kubernetes service named myapp in namespace prod?

easy

A. prod.myapp.svc.cluster.local

B. myapp.svc.prod.cluster.local

C. myapp.prod.svc.cluster.local

D. svc.myapp.prod.cluster.local

Solution

1. Step 1: Recall Kubernetes DNS naming convention

   The format is <service>.<namespace>.svc.cluster.local.

2. Step 2: Match the service and namespace

   For service myapp in namespace prod, the DNS name is myapp.prod.svc.cluster.local.

3. Final Answer:

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

4. Quick Check:

   Service.Namespace.svc.cluster.local = B [OK]

Hint: Service DNS = service.namespace.svc.cluster.local [OK]

Common Mistakes:

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

3. Given a pod in namespace dev trying to reach a service named backend, what DNS name should the pod use to connect to the service?

medium

A. backend.dev.svc.cluster.local

B. backend.svc.dev.cluster.local

C. dev.backend.svc.cluster.local

D. backend.dev.cluster.local

Solution

1. Step 1: Understand the DNS naming pattern

   Kubernetes services are accessible via service.namespace.svc.cluster.local.

2. Step 2: Apply the pattern for service backend in namespace dev

   The correct DNS name is backend.dev.svc.cluster.local.

3. Final Answer:

   backend.dev.svc.cluster.local -> Option A

4. Quick Check:

   Service.Namespace.svc.cluster.local = A [OK]

Hint: Use service.namespace.svc.cluster.local for full DNS name [OK]

Common Mistakes:

• Mixing up namespace and service order
• Leaving out 'svc' in the DNS name
• Using incomplete domain suffix

4. A pod tries to connect to db.prod.svc.cluster.local but fails. Which of these is the most likely cause?

medium

A. The pod is using the IP address instead of DNS name

B. The pod is in the same namespace as the service

C. The cluster DNS is disabled but service exists

D. The service db does not exist in namespace prod

Solution

1. Step 1: Check if the service exists in the namespace

   If the service db is missing in prod, DNS lookup fails.

2. Step 2: Consider DNS and pod namespace

   Using DNS name requires the service to exist; pod namespace or IP usage doesn't cause DNS failure.

3. Final Answer:

   The service db does not exist in namespace prod -> Option D

4. Quick Check:

   Missing service = DNS failure [OK]

Hint: Check service existence in namespace if DNS lookup fails [OK]

Common Mistakes:

• Assuming DNS is always enabled
• Confusing pod namespace with service namespace
• Thinking IP use breaks DNS resolution

5. You have a multi-namespace Kubernetes cluster with services named api in namespaces dev and prod. How can a pod in dev namespace connect to the api service in prod namespace using DNS?

hard

A. Use the full DNS name api.prod.svc.cluster.local

B. Use just api since it resolves across namespaces

C. Use api.dev.svc.cluster.local and specify namespace in config

D. Use the IP address of the prod service directly

Solution

1. Step 1: Understand cross-namespace DNS resolution

   Within a namespace, service names resolve locally; cross-namespace requires full DNS name.

2. Step 2: Apply full DNS name for cross-namespace access

   To reach api in prod from dev, use api.prod.svc.cluster.local.

3. Final Answer:

   Use the full DNS name api.prod.svc.cluster.local -> Option A

4. Quick Check:

   Cross-namespace = full DNS name [OK]

Hint: Cross-namespace access needs full DNS name service.namespace.svc.cluster.local [OK]

Common Mistakes:

• Assuming service name alone resolves across namespaces
• Using wrong namespace in DNS name
• Relying on IP addresses which can change