In the context of the Certified Kubernetes Administrator (CKA) exam, Service Discovery is fundamental because Kubernetes Pods are ephemeral; their IP addresses change dynamically upon recreation, rendering static IP configuration impossible. Kubernetes abstracts this complexity using Services and s…In the context of the Certified Kubernetes Administrator (CKA) exam, Service Discovery is fundamental because Kubernetes Pods are ephemeral; their IP addresses change dynamically upon recreation, rendering static IP configuration impossible. Kubernetes abstracts this complexity using Services and solves the connectivity challenge primarily through its built-in DNS system, implemented via CoreDNS.
While Kubernetes initially supported service discovery via Environment Variables (injecting host/port variables into Pods at startup), this method is dependent on creation order. Consequently, Cluster DNS is the industry standard. CoreDNS runs as a Deployment in the 'kube-system' namespace and exposes a Service (usually named 'kube-dns'). It watches the Kubernetes API; whenever a Service is created, CoreDNS automatically generates a DNS record mapping the Service name to its ClusterIP.
Key concepts for the exam include the Fully Qualified Domain Name (FQDN) hierarchy: '<service-name>.<namespace>.svc.cluster.local'. Within the same namespace, a Pod can access a Service simply by its name. Across namespaces, the namespace must be appended (e.g., 'db-service.dev'). Technically, the Kubelet configures every Pod's '/etc/resolv.conf' to point to the CoreDNS Service IP as the nameserver.
For CKA troubleshooting, you must know how to: 1) Verify CoreDNS Pods are 'Running' via 'kubectl get pods -n kube-system', 2) Inspect the CoreDNS ConfigMap containing the 'Corefile', and 3) Debug resolution using a temporary utility Pod (e.g., 'kubectl run test --image=busybox:1.28 --restart=Never -- nslookup my-service').
Service Discovery and DNS in Kubernetes (CKA)
Why is it Important? In a Kubernetes cluster, Pods are ephemeral (temporary). They are created, destroyed, and rescheduled frequently, meaning their IP addresses change constantly. Consequently, hardcoding IP addresses for communication between microservices is unreliable and impractical. Service Discovery and DNS solve this by providing a stable, name-based method for services to locate and communicate with each other, regardless of the underlying Pod IPs.
What is it? Kubernetes includes a built-in DNS cluster add-on, typically CoreDNS, which acts as the service discovery mechanism. It automatically assigns DNS records to Services and Pods. This allows applications to connect to a database using a stable name like mysql-service rather than tracking a shifting list of Pod IP addresses.
How it Works 1. CoreDNS Deployment: CoreDNS runs as a Deployment in the kube-system namespace. It is exposed via a Service (usually named kube-dns). 2. Pod Configuration: When a Pod is created, the kubelet automatically configures the Pod's /etc/resolv.conf file to use the kube-dns Service IP as its nameserver. 3. Resolution Logic: When an application queries a hostname, the request goes to CoreDNS. CoreDNS checks its database for a matching Service IP (ClusterIP). 4. FQDN Structure: The standard Fully Qualified Domain Name for a service is: service-name.namespace.svc.cluster.local.
How to Answer Questions in the Exam In the CKA exam, questions regarding DNS usually focus on troubleshooting connectivity issues or configuring custom DNS entries. 1. Validate CoreDNS: Check if the CoreDNS pods are running: kubectl get pods -n kube-system -l k8s-app=kube-dns. 2. Check Service Existence: Ensure the Service you are trying to reach actually exists and has a valid ClusterIP. 3. Verify Endpoints: DNS resolves the Service IP, but the Service needs Endpoints to function. Check with kubectl get ep. 4. Test Resolution: You must know how to spin up a temporary pod to run nslookup to verify if names are resolving to IPs.
Exam Tips: Answering Questions on Service Discovery and DNS 1. Memorize the Troubleshooting Command: Use the legacy busybox image (v1.28) which has the most reliable nslookup implementation for testing. Command: kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup target-service-name. 2. Cross-Namespace Syntax: If a question asks you to connect to a service in a different namespace, you must append the namespace to the hostname (e.g., use db-service.prod instead of just db-service). 3. The Corefile: If asked to modify DNS behavior (like forwarding to an external DNS), look for the ConfigMap named coredns in the kube-system namespace. This contains the Corefile configuration. 4. Service vs. Pod DNS: Remember that Services resolve to service.namespace.svc.cluster.local, while Pods resolve to pod-ip-dashed.namespace.pod.cluster.local.