CKA-23-Service Discovery in Kubernetes

Learn Kubernetes service discovery patterns and how workloads find each other reliably inside a cluster.

For CKA preparation, do not treat this as a definition to memorize. Treat it as a cluster behavior you should be able to inspect, configure, and verify under time pressure. This guide explains the operational purpose, the important moving parts, and a safe way to reason about it.

What you will learn: how service discovery in kubernetes fits into networking, what to check first, and the mistakes that commonly lead to failed changes.

How applications locate one another as Pods scale and change

In a distributed application, the checkout service must find the payment service, and the frontend must find the API. Hard-coded Pod IPs fail quickly because Pods are disposable. Kubernetes solves discovery mainly through Services and DNS.

Assume a Service named payments selects Pods with app: payments:

apiVersion: v1
kind: Service
metadata:
  name: payments
spec:
  selector:
    app: payments
  ports:
    - port: 80
      targetPort: 8080

A client in the same namespace calls http://payments. DNS resolves the stable Service name, and the cluster directs traffic to an available endpoint. As payment Pods scale up, roll out, or fail, EndpointSlices are updated automatically.

Kubernetes also injects Service-related environment variables into Pods, but DNS is generally preferable. Environment variables exist only for Services created before the Pod starts and can clutter the environment in namespaces with many Services.

Headless Services provide a different discovery model. With clusterIP: None, DNS returns individual Pod addresses rather than one virtual Service IP. Databases and clustered systems may use this to discover peers and make their own routing decisions.

Troubleshooting has three distinct questions:

kubectl get service payments
kubectl get endpointslices -l kubernetes.io/service-name=payments
kubectl run test --rm -it --image=curlimages/curl -- curl http://payments

Does the name resolve? Does the Service have endpoints? Can the destination application answer? Keeping those questions separate avoids blaming DNS for a selector mismatch or blaming the application for a NetworkPolicy.

Service discovery is less about finding a machine and more about finding a capability. Clients ask for payments; Kubernetes handles which healthy Pod currently provides it. This small abstraction is what allows a cluster to change constantly without forcing every application to maintain its own address book.

Practical CKA Workflow

When you work with this topic in a live cluster, use a repeatable approach:

1. Start with the Service, Pod labels, and EndpointSlices before changing configuration.
2. Use a temporary diagnostic Pod to test the same DNS name, port, and path that the workload uses.
3. Check NetworkPolicies only after confirming that names and endpoints are correct.

Useful starting commands are:

kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl describe <resource-type> <resource-name> -n <namespace>

Replace the placeholders with the resource relevant to the task. The goal is to use evidence from the API server rather than guessing from a single symptom.

Common Mistakes

• Changing several variables at once and losing the ability to identify the actual cause.
• Using a cluster-wide setting when a namespace- or workload-scoped change is sufficient.
• Applying a manifest without checking labels, selectors, names, and the resulting events.
• Assuming a resource is healthy because it exists; always verify its observed state and its effect on the workload.

CKA Exam Takeaway

In the exam, read the requested outcome carefully, make the smallest declarative change that achieves it, and validate it with kubectl. A correct manifest is only half the task—the cluster must reach the intended state.

Originally published at https://cloudopsblog.com on July 13, 2026.