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

This tutorial guides you through troubleshooting a common Kubernetes scenario: a deployment is reporting ready pods, but the associated service isn’t advertising any endpoints. This indicates a disconnect between the deployment and the service, preventing external traffic from reaching your application. We’ll use Kubernetes YAML and `kubectl` to diagnose and resolve this issue.

Example 1: Initial State – The Problem

Let’s set up a basic scenario where a deployment is running but the service isn’t correctly selecting the pods.

kubectl create deployment my-app --image=nginx:latest --replicas=3
kubectl expose deployment my-app --port=80 --type=ClusterIP
kubectl get deployments
kubectl get pods
kubectl get services

After executing these commands, you should observe the following:

• The deployment `my-app` has three running pods.
• The service `my-app` exists but has no endpoints listed under the `EXTERNAL-IP` or `CLUSTER-IP` columns.

This is the core problem we’re addressing. The pods are healthy, but the service isn’t aware of them.

Example 2: Incorrect Service Selector – The Root Cause

The most common cause is an incorrect service selector. The service’s selector must match the labels applied to the pods in the deployment. Let’s intentionally misconfigure this.

kubectl apply -f service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: wrong-app # Incorrect label
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
  clusterIP: None # Explicitly no clusterIP

Now, run these commands again:

kubectl get deployments
kubectl get pods
kubectl get services

You'll find that the service still has no endpoints. The service selector `app: wrong-app` doesn't match the labels on the pods created by the deployment (which have `app: my-app`). This is the critical error.

Example 3: Correcting the Service Selector - The Resolution

To fix this, update the service YAML to correctly match the deployment's labels.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app  # Correct label
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
  clusterIP: None

Apply the corrected service:

kubectl apply -f service.yaml

Finally, verify the results:

kubectl get deployments
kubectl get pods
kubectl get services

The service should now have endpoints listed, indicating that it's successfully selecting the pods from the deployment. The `kubectl get services` command will show the `CLUSTER-IP` of the service, alongside the endpoints. The issue is resolved.

Key Takeaways

• Service Selectors are Crucial: The service selector is the primary mechanism for the service to find and route traffic to the pods in a deployment.
• Label Consistency: Ensure the labels on your pods and service selectors are exactly the same. Typos or different casing can cause issues.
• Verification is Key: Regularly use `kubectl get services` and inspect the endpoint information to confirm your service is correctly selecting your pods.

By understanding the relationship between deployments, services, and selectors, you can efficiently troubleshoot common Kubernetes issues like this one.