Service discovery via DNS in Kubernetes - Mini Project: Build & Apply

Service discovery via DNS in Kubernetes

📖 Scenario: You are working with a Kubernetes cluster where multiple microservices need to find each other to communicate. Kubernetes provides a built-in DNS service that allows pods to discover services by their names.In this project, you will create a simple Kubernetes Service and a Pod that uses DNS to discover that Service by its name.

🎯 Goal: Build a Kubernetes Service named my-service and a Pod named my-pod that uses DNS to discover my-service by its name and prints the resolved IP address.

📋 What You'll Learn

Create a Kubernetes Service named my-service exposing port 80

Create a Pod named my-pod with a container running busybox

Configure the Pod to resolve my-service using DNS

Print the resolved IP address of my-service inside the Pod

💡 Why This Matters

🌍 Real World

In real Kubernetes clusters, services need to find each other by name to communicate. DNS-based service discovery is a core feature that makes microservices talk easily.

💼 Career

Understanding Kubernetes service discovery is essential for DevOps engineers and cloud-native developers to deploy and manage scalable applications.

1

Create a Kubernetes Service named my-service

Write a YAML manifest to create a Kubernetes Service named my-service that exposes port 80 and targets pods with label app: myapp. Use ClusterIP as the service type.

Kubernetes

# Write the YAML manifest for the Service named my-service
# Your code here

Hint

Use kind: Service and specify metadata.name as my-service. The selector should match pods labeled app: myapp. Expose port 80.

2

Create a Pod named my-pod with label app: myapp

Write a YAML manifest to create a Pod named my-pod with label app: myapp. The Pod should run a busybox container that sleeps for 3600 seconds.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

# Write the YAML manifest for the Pod named my-pod
# Your code here

Hint

Use kind: Pod with metadata.name as my-pod. Add label app: myapp. Use busybox image and command sleep 3600.

3

Add a command in the Pod to resolve my-service using DNS

Modify the busybox container command in my-pod to run nslookup my-service to resolve the service DNS name, then sleep for 3600 seconds.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: myapp
spec:
  containers:
  - name: busybox
    image: busybox
    # Change the command to run nslookup my-service then sleep
    # Your code here

Hint

Use command: ["sh", "-c", "nslookup my-service && sleep 3600"] to run DNS lookup and then keep the container alive.

4

Print the resolved IP address of my-service inside the Pod

Run the Pod and check the logs to see the output of nslookup my-service which shows the IP address resolved by Kubernetes DNS.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: myapp
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "nslookup my-service && sleep 3600"]

# Run 'kubectl logs my-pod' to see the IP address output
# Your code here

Hint

Use kubectl logs my-pod to see the output of nslookup my-service which includes the IP address.

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