Introduction

An Ingress sends traffic to a Service, and the Service sends traffic only to ready endpoints. If the Service has none, the Ingress often returns 503 Service Unavailable even though Pods appear to exist somewhere in the namespace. The usual problem is not the Ingress controller itself. It is that the Service selector, readiness state, or namespace assumptions leave the Service with no healthy backends.

Symptoms

  • The Ingress returns 503 Service Unavailable
  • kubectl get endpoints or kubectl get endpointslices shows no backend addresses
  • Pods are running, but the Service still has no endpoints
  • A recent label change, rollout, or readiness probe change immediately preceded the outage

Common Causes

  • The Service selector no longer matches the Pod labels
  • Pods are running but not Ready, so they are excluded from endpoints
  • The backend Deployment rolled out a label change without updating the Service
  • The wrong namespace or Service name is referenced in the Ingress path

Step-by-Step Fix

  1. 1.Check whether the Service actually has endpoints
  2. 2.This immediately tells you whether the 503 is an endpoint problem or an Ingress-layer problem.
bash
kubectl get endpoints my-service
kubectl get endpointslices -l kubernetes.io/service-name=my-service
  1. 1.Compare the Service selector to live Pod labels
  2. 2.Pods can be running normally while still being invisible to the Service if the selector drifted.
bash
kubectl get service my-service -o yaml
kubectl get pods --show-labels
  1. 1.Check Pod readiness and probe failures
  2. 2.A Pod that is not Ready will not appear as a backend endpoint even if the container process is up.
bash
kubectl describe pod my-pod
  1. 1.Retest the Ingress after the Service regains endpoints
  2. 2.Once the selector and readiness path are correct, the 503 usually clears without changing the Ingress object itself.

Prevention

  • Treat Deployment labels and Service selectors as one change set during rollouts
  • Monitor endpoint count for critical Services, not just Pod count
  • Use readiness probes that reflect actual request readiness
  • Validate namespace and Service references when modifying Ingress rules