Service discovery via DNS in Kubernetes - Step-by-Step Execution

Process Flow - Service discovery via DNS

Pod starts

↓

Pod queries DNS for service name

↓

DNS server receives query

↓

DNS server looks up service IP

↓

DNS server returns service IP

↓

Pod connects to service IP

Pods use DNS to find services by name. The DNS server resolves the service name to its IP, enabling communication.

Execution Sample

Kubernetes

kubectl run busybox --image=busybox --rm -it --restart=Never -- sh -c "nslookup my-service && ping my-service"

A pod runs a busybox container, then queries DNS for 'my-service' and pings it to test connectivity.

Process Table

Step	Action	Input/Query	DNS Response	Pod Behavior
1	Pod starts	-	-	Pod is running and ready
2	Pod runs nslookup	Query: my-service.default.svc.cluster.local	Response: 10.96.0.10	Pod receives IP of service
3	Pod runs ping	Target: my-service	Uses IP 10.96.0.10	Pod sends ICMP packets to service IP
4	Ping succeeds	-	-	Pod confirms service is reachable
5	Pod stops querying	-	-	Service discovery complete

💡 Pod successfully resolves service name to IP and confirms connectivity

Status Tracker

Variable	Start	After nslookup	After ping	Final
service_name	my-service	my-service	my-service	my-service
service_ip	unknown	10.96.0.10	10.96.0.10	10.96.0.10
ping_status	not started	not started	success	success

Key Moments - 2 Insights

Why does the pod use the full DNS name 'my-service.default.svc.cluster.local' during lookup?

The pod appends the namespace and cluster domain to the service name to form the full DNS name, ensuring the DNS server can resolve it correctly. This is shown in execution_table step 2 where the query includes the full domain.

What happens if the DNS server does not respond with an IP?

The pod cannot resolve the service name, so it cannot connect. This would be seen as no IP in the DNS Response column in execution_table step 2, causing ping to fail in step 3.

Visual Quiz - 3 Questions

Look at the execution table, what IP does the pod receive for 'my-service' at step 2?

A 127.0.0.1

B 192.168.1.1

C 10.96.0.10

D No IP received

💡 Hint

Check the DNS Response column in execution_table row 2

At which step does the pod confirm that the service is reachable?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for 'Ping succeeds' in the Action column of execution_table

If the pod could not resolve the service IP, what would change in the variable_tracker?

A ping_status would be 'success'

B service_ip would remain 'unknown' after nslookup

C service_name would change

D service_ip would be '10.96.0.10'

💡 Hint

Check the service_ip row in variable_tracker after nslookup

Concept Snapshot

Service discovery in Kubernetes uses DNS.
Pods query DNS with full service name.
DNS returns service cluster IP.
Pods use IP to connect to service.
If DNS fails, connection fails.

Full Transcript

In Kubernetes, pods find services by asking the DNS server for the service's IP address. When a pod starts, it can run a DNS query like nslookup for the service name, which includes the namespace and cluster domain. The DNS server responds with the service's cluster IP. The pod then uses this IP to connect, for example by pinging it. If the DNS lookup fails, the pod cannot reach the service. This process allows pods to discover services dynamically by 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