Automate Service Discovery

You’ve containerized your Python app, scaled it into multiple pods, and watched it tumble into the chaos of a dynamic environment: pod IPs churn on every restart, replicas come and go, and your API clients are pointing at a ghost address. Manually hardcoding IPs or scraping kubectl get pods is a one-way ticket to downtime. That’s the pain this lesson kills. You’ll learn how to automate service discovery for Python pods using Kubernetes Services — the built-in mechanism that gives your pods a stable network identity and load-balances traffic without you lifting a finger.

The problem this lesson solves

Every time a deployment rolls out, a pod dies, or the cluster autoscaler kicks in, pod IPs change. If your Python services talk to each other by IP or hostname that you wrote in a config file, you’re in for a world of hurt. Here’s what you’re likely facing without automated discovery:

• Broken connections — one service can’t find another because the IP it cached is gone.
• Manual operations overhead — you SSH into boxes, edit hosts files, or run fragile scripts to update addresses.
• Load balancing gaps — you have 5 replicas, but all traffic hammers one pod because there’s no native routing.
• Scaling friction — adding or removing replicas breaks your hand-rolled discovery logic.

The Kubernetes solution is a Service — an abstraction that sits in front of a set of pods, gives them a permanent virtual IP (ClusterIP), and discovers eligible pods automatically via label selectors. With this, your Python client code can rely on a stable DNS name (my-service) and never worry about the underlying pod IPs again. This lesson hands you the tools to automate service discovery for your Python pods and stop fighting the platform.

Core concept / mental model

Think of a Kubernetes Service as a receptionist for your pods. You tell the receptionist which pods you care about by labeling them (e.g., app: my-api). The receptionist keeps a live list of all pods with that label, assigns them a single phone number (the ClusterIP), and forwards every incoming call to one available pod. If a pod goes away, the receptionist just crosses it off the list. If a new pod is added, it’s added to the directory. Your Python clients only need to know the receptionist’s number — not each individual pod’s.

This model relies on two core mechanisms inside Kubernetes:

• Selector-based discovery — The Service’s selector field matches pod labels. The control plane watches the API for pods that match, then adds or removes their endpoints.
• DNS-based naming — Kubernetes’ internal DNS (CoreDNS) maps a Service name like my-api to its ClusterIP. Every pod gets a /etc/resolv.conf pointing to CoreDNS, so Python code can use simple names like http://my-api:8000.

Pro tip: The entire discovery loop is event-driven. When a pod is created, destroyed, or recreated, the Endpoints object updates within seconds. Your Python code never needs to poll or cache IPs.

How it works step by step

Follow the sequence below to see the moving parts of automated discovery for Python pods.

1. Define a deployment — You create a Python app deployment and set a matchLabels selector like app: my-api. Every pod gets that label.
2. Create a Service — You write a YAML manifest with a selector that matches the same label. The Service has a port (e.g., 80) and a targetPort (e.g., 8000) mapping to your container’s port.
3. Control plane acts — Kubernetes’ controller manager sees the Service and queries the pod list. It creates an Endpoints object listing all matching pod IPs and their ports.
4. DNS registration — CoreDNS creates a DNS record for the Service name (e.g., my-api.default.svc.cluster.local and the short alias my-api).
5. Client pod resolves — When any pod calls my-api, CoreDNS returns the Service’s ClusterIP. The kube-proxy on each node then load-balances the connection to one of the live pod IPs.
6. Automatic updates — If a pod is deleted or new replicas are spawned, the Endpoints list refresh automatically, and DNS continues to resolve the same name.

This is all standard, out-of-the-box behavior — no extra tooling required. The only “code” you write is YAML manifests and, optionally, a small Python client using socket.getaddrinfo() or an HTTP library that respects DNS.

Hands-on walkthrough

Let’s build a full example. Start with a simple Python web server (using Flask or the built-in http.server) and containerize it.

Step 1: Deploy your Python app

Create deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
      - name: api
        image: my-api:latest
        ports:
        - containerPort: 8000

Apply it:

kubectl apply -f deployment.yaml
kubectl get pods -l app=my-api

# Output (IPs will vary)
NAME                      READY   STATUS    RESTARTS   AGE
my-api-6b9c8d4f7f-abc01   1/1     Running   0          10s
my-api-6b9c8d4f7f-abc02   1/1     Running   0          10s
my-api-6b9c8d4f7f-abc03   1/1     Running   0          10s

Step 2: Create the Service

Create service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  selector:
    app: my-api
  ports:
  - port: 80
    targetPort: 8000

Apply and inspect:

kubectl apply -f service.yaml
kubectl get svc my-api

# Output
NAME     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
my-api   ClusterIP   10.96.123.45    <none>        80/TCP    5s

Step 3: Use discovery from a Python client pod

Now create a simple Python script that discovers and calls the service. Run it as a one-off pod:

import socket
import urllib.request

# Resolve the service name to the ClusterIP
ip = socket.gethostbyname("my-api")
print(f"Resolved my-api to {ip}")

# Call the service using the DNS name
response = urllib.request.urlopen("http://my-api:80/ping")
print(response.status, response.read().decode())

Run it inside the cluster.

kubectl run -it --rm client --image=python:3.12 --restart=Never -- python -c "import socket; print(socket.gethostbyname('my-api'))"

# Output (example)
10.96.123.45

Step 4: Watch automatic discovery in action

Delete one pod and observe the Endpoints update:

kubectl delete pod my-api-6b9c8d4f7f-abc01
kubectl get endpoints my-api

# Output (the pod IP list changes)
NAME     ENDPOINTS                            AGE
my-api   10.244.0.5:8000,10.244.0.7:8000      1m

The Service automatically drops the dead pod and keeps the two healthy ones. A new replicaset replaces the deleted pod, and the endpoints list grows back to three. Your Python client keeps running with the same DNS name and never notices.

Pro tip: In your Python app, always use the Service name (e.g., http://my-api:80) rather than the ClusterIP. If the Service is recreated, the IP may change, but the DNS name stays stable.

Compare options / when to choose what

Not all discovery patterns are created equal. Here’s a breakdown of what fits when.

When to choose what:

• Use ClusterIP for the vast majority of internal Python service‑to‑service calls — it’s automatic, reliable, and simple.
• Use a headless service when you need to discover individual pod IPs (e.g., for a peer‑to‑peer Python worker pool) or when you need sticky per‑pod communication.
• Use an ExternalName service when your pod needs a stable DNS alias to an external database or API without exposing an internal IP.
• Use an Ingress only when external clients need HTTP access — it complements, not replaces, service discovery.

Troubleshooting & edge cases

Let’s diagnose the most common failures you’ll hit.

• Problem: “Name or service not known” when resolving my-api in Python.
• Cause: The Service doesn’t exist or is in a different namespace.
• Fix: Use the fully qualified name my-api.<namespace>.svc.cluster.local or run the client in the same namespace. Check kubectl get svc -A.

• Check: kubectl get endpoints my-api — if ENDPOINTS is empty, no pods match the selector.

• Problem: Endpoints list is empty despite existing pods.

• Cause: The Service’s selector doesn’t match the pod labels.

• Fix: Verify pod labels with kubectl get pods --show-labels. Ensure the selector in the Service exactly matches the labels in the deployment’s template.metadata.labels.

• Problem: Connection refused from client pod.

• Cause: The targetPort doesn’t match the port your Python app listens on.

• Fix: Check your container’s listening port (e.g., 8000). Update targetPort accordingly. In Python, use app.run(port=8000) or http.server.HTTPServer binding to 0.0.0.0:8000.

• Problem: DNS resolution works, but traffic isn’t load balanced.

• Cause: Using a headless service or an external name service.

• Fix: If you need load balancing, stick to a normal ClusterIP service. Headless services bypass the kube-proxy.

• Edge case: Headless service DNS returns multiple A records.

• Your Python code must handle multiple IPs. Use socket.getaddrinfo to get all addresses and implement retry logic.

What you learned & what's next

You now know how to automate service discovery for Python pods using Kubernetes Services. You understand the underlying event-driven model, you can write deployment and Service manifests, you can test discovery from a Python client, and you can troubleshoot the most common failures. This means your Python microservices can find each other reliably, scale without manual updates, and recover from pod churn automatically.

What’s next? In the next lesson, you’ll learn how to configure external access — exposing your Python API to users outside the cluster using NodePort or LoadBalancer services, then Ingress for HTTP routing. This extends the same core idea of stable endpoints to the outside world. Master internal discovery first, and you’ll glide through external access.