Kubernetes Tutorial: Diagnose Why a Deployment Has Ready Pods but Its Service Has No Endpoints

This tutorial guides you through diagnosing a common Kubernetes issue: a Deployment successfully creates pods, but the associated Service doesn’t expose them. We’ll use YAML manifests and `kubectl` commands to identify and resolve this problem. This focuses exclusively on Kubernetes components.

Understanding the Problem

A Deployment manages the desired state of your application, creating and updating pods. A Service provides a stable IP address and DNS name to access those pods. If a Service has no endpoints, it means no pods are being targeted by the Service, despite the Deployment’s successful creation.

Example 1: Initial Setup – The Problem

Let’s set up a simple scenario to illustrate the issue. We’ll create a Deployment and a Service. The key part of this example is intentionally introducing a selector mismatch.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest
        ports:
        - containerPort: 80
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app-container # Incorrect selector!
  ports:
    - port: 80
      targetPort: 80
  type: LoadBalancer

Now, run these commands:

• `kubectl apply -f deployment.yaml`
• `kubectl apply -f service.yaml`

Then, check the Service:

• `kubectl get service my-app-service`

You’ll likely see that the Service has no endpoints. The crucial error here is the `selector` in the Service. It’s targeting `app: my-app-container`, while the Deployment is targeting `app: my-app`. Kubernetes won’t route traffic to pods that don’t match the Service’s selector.

Example 2: Correcting the Selector – The Solution

To fix this, we need to update the Service’s selector to match the Deployment’s labels.

# service.yaml (Corrected)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app # Corrected selector
  ports:
    - port: 80
      targetPort: 80
  type: LoadBalancer

After updating the Service manifest, run:

• `kubectl apply -f service.yaml`

Now, check the Service again:

• `kubectl get service my-app-service`

The Service should now display the correct number of endpoints (3 in this case), indicating that traffic is being routed to the pods created by the Deployment.

Example 3: Verification and Troubleshooting – Events

Let’s confirm the issue and the solution by examining Kubernetes events. This is a critical step in troubleshooting.

• `kubectl describe service my-app-service`

This command provides detailed information about the Service, including its selector, endpoints, and any related events. Look for events related to the Service creation or updates. Incorrect selectors are often logged as errors here. Also check:

• `kubectl get events –sort-by=’.lastTimestamp’`

This will show you the most recent events in the cluster, allowing you to track the deployment and service process and identify any configuration issues.

Summary

This tutorial demonstrated a common Kubernetes issue—a Deployment running successfully but a Service lacking endpoints—and provided a clear solution: ensuring the Service’s selector accurately matches the labels used by the Deployment to target the pods.