How Service Discovery Works in Kubernetes: Explained Simply

In Kubernetes, service discovery allows pods to find and communicate with each other automatically using Services. Kubernetes provides this by assigning a stable DNS name and IP to each Service, which pods use to connect without needing to know pod IPs directly.

Syntax

Kubernetes service discovery mainly uses Service resources. A Service defines a logical set of pods and a policy to access them.

Key parts of a Service manifest:

• apiVersion: Kubernetes API version.
• kind: Always Service for service discovery.
• metadata.name: The service name used for DNS.
• spec.selector: Labels to select pods.
• spec.ports: Ports exposed by the service.
• spec.type: Service type (ClusterIP, NodePort, LoadBalancer).

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Example

This example shows a simple Service and a Pod that uses DNS to discover the Service.

The Service named my-service selects pods with label app: my-app. Pods can access it via DNS name my-service.default.svc.cluster.local.

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: busybox
    command: ["sh", "-c", "nslookup my-service"]

Output

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

Name:      my-service.default.svc.cluster.local
Address 1: 10.96.123.45 my-service.default.svc.cluster.local

Common Pitfalls

• Wrong label selectors: If the Service selector labels don't match pod labels, the Service won't route traffic.
• Using pod IPs directly: Pod IPs change; always use Service DNS names.
• Not waiting for DNS propagation: DNS may take a moment to update after Service creation.
• Ignoring namespaces: DNS names include namespaces; use full names or correct namespace context.

yaml

apiVersion: v1
kind: Service
metadata:
  name: wrong-service
spec:
  selector:
    app: wrong-label
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

# This Service won't route to pods if pods have label app: my-app

# Correct selector example:
apiVersion: v1
kind: Service
metadata:
  name: correct-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Quick Reference

Service Discovery Tips:

• Use Service resources to expose pods.
• Access services via DNS names: <service>.<namespace>.svc.cluster.local.
• Use ClusterIP type for internal discovery.
• Ensure pod labels match Service selectors exactly.
• Use kubectl get svc and kubectl get pods --show-labels to verify setup.

Key Takeaways

Kubernetes service discovery uses Services to provide stable DNS names for pods.

Pods communicate using Service DNS names, not pod IPs, which can change.

Service selectors must match pod labels exactly for routing to work.

ClusterIP Services enable internal communication within the cluster.

Always include namespace in DNS names when accessing services across namespaces.