0
0
Kubernetesdevops~10 mins

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

Choose your learning style9 modes available
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
StepActionInput/QueryDNS ResponsePod Behavior
1Pod starts--Pod is running and ready
2Pod runs nslookupQuery: my-service.default.svc.cluster.localResponse: 10.96.0.10Pod receives IP of service
3Pod runs pingTarget: my-serviceUses IP 10.96.0.10Pod sends ICMP packets to service IP
4Ping succeeds--Pod confirms service is reachable
5Pod stops querying--Service discovery complete
💡 Pod successfully resolves service name to IP and confirms connectivity
Status Tracker
VariableStartAfter nslookupAfter pingFinal
service_namemy-servicemy-servicemy-servicemy-service
service_ipunknown10.96.0.1010.96.0.1010.96.0.10
ping_statusnot startednot startedsuccesssuccess
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
Test your understanding
Look at the execution table, what IP does the pod receive for 'my-service' at step 2?
A127.0.0.1
B192.168.1.1
C10.96.0.10
DNo 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?
AStep 4
BStep 3
CStep 2
DStep 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?
Aping_status would be 'success'
Bservice_ip would remain 'unknown' after nslookup
Cservice_name would change
Dservice_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.