Service discovery via DNS in Kubernetes - Commands & Configuration

Introduction

When you run multiple parts of an application in Kubernetes, they need to find and talk to each other. Service discovery via DNS lets these parts find each other by simple names instead of complicated IP addresses.

When you want your app components to communicate without hardcoding IP addresses.

When you deploy a database and want your app to find it by a simple name.

When you scale your app and new copies need to be reachable automatically.

When you want to connect microservices inside the same Kubernetes cluster.

When you want to avoid manual updates of service addresses after restarts.

Config File - service.yaml

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-app-container
    image: nginx
    ports:
    - containerPort: 8080
  dnsPolicy: ClusterFirst

This file creates a Service named my-app-service that selects pods with label app: my-app. It exposes port 80 and forwards traffic to port 8080 on the pods.

The Pod runs an nginx container labeled app: my-app so the service can find it.

The dnsPolicy: ClusterFirst ensures the pod uses Kubernetes DNS for service discovery.

Commands

This command creates the service and pod defined in the service.yaml file so they can start running and be discoverable.

Terminal

kubectl apply -f service.yaml

Expected Output

service/my-app-service created

pod/my-app-pod created

Check that the pod is running and ready to receive traffic.

Terminal

kubectl get pods

Expected Output

NAME          READY   STATUS    RESTARTS   AGE

my-app-pod    1/1     Running   0          10s

Inside the pod, this command looks up the DNS name of the service to verify that service discovery via DNS works.

Terminal

kubectl exec my-app-pod -- nslookup my-app-service

Expected Output

Server:    10.96.0.10

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local



Name:      my-app-service.default.svc.cluster.local

Address 1: 10.96.123.45

Get details about the service including its cluster IP address which pods use to connect.

Terminal

kubectl get svc my-app-service

Expected Output

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE

my-app-service   ClusterIP   10.96.123.45    <none>        80/TCP    1m

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes automatically creates DNS names for services so pods can find each other by simple names.

Common Mistakes

Not labeling pods correctly to match the service selector

The service cannot find any pods to send traffic to, so DNS lookup works but connections fail.

Make sure pod labels exactly match the service selector labels.

Using dnsPolicy other than ClusterFirst in pods

Pods may not use Kubernetes DNS and fail to resolve service names.

Set dnsPolicy to ClusterFirst (default) to enable service DNS resolution.

Trying to access service DNS from outside the cluster without extra setup

Service DNS names only resolve inside the cluster by default.

Use port forwarding or expose the service externally if needed.

Summary

Create a Service with a selector to group pods and expose ports.

Deploy pods with matching labels and dnsPolicy ClusterFirst for DNS resolution.

Use kubectl exec with nslookup inside pods to verify service DNS names resolve.

Check service details with kubectl get svc to find cluster IP addresses.

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