What Happens When an Unready Pod Gets Traffic?

In Kubernetes, Pod readiness is crucial in determining whether a Pod should receive traffic from Services. Kubernetes uses readiness probes to decide if a Pod is ready to serve requests. But what if a Pod is unready and still receives traffic?

1. What Does “Unready” Mean?

A Pod is marked “Ready” when:

All of its containers pass their readiness probes
Kubernetes considers it healthy and able to serve traffic

Readiness Probe Example:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

If the /health endpoint returns HTTP 200, the pod is considered ready.

2. How Kubernetes Uses Readiness

Kubernetes uses the Endpoints Controller to associate Pods with Services. A Pod must be:

Running
Ready

Only then is it added to the Endpoints list of the Service.

kubectl get endpoints my-service

This lists the IPs of Pods that are ready to receive traffic.

If a Pod is unready, it is excluded from the list, and kube-proxy does not route traffic to it.

3. So, Can Unready Pods Still Get Traffic?

Under normal circumstances: No.

However, exceptions and misconfigurations can cause traffic to hit unready Pods.

4. Situations Where Unready Pods Receive Traffic

1. No Readiness Probe Defined

If you don’t specify a readiness probe:

Kubernetes assumes the container is always ready after it starts.
So even if your app isn’t fully initialized, it starts receiving traffic immediately.

Consequence: Traffic hits the pod before it’s ready to serve, causing failed requests or timeouts.

2. Startup Delay Without Readiness Probe

Applications with long boot times (e.g., Java Spring Boot) may not be ready to handle requests immediately.

If no readiness probe exists, kube-proxy sends traffic as soon as the container is started.

Consequence: Clients may see errors even though the app is technically working—just not ready yet.

3. Pod Recovered but Probes Misconfigured

Sometimes readiness probes are misconfigured to always return success—even during downtime.

Example: /healthz always returns HTTP 200 even if the database is down.

This tricks Kubernetes into thinking the Pod is ready.

Consequence: Pod receives traffic while it can’t process requests properly.

4. Direct Access via Pod IP

Even if a Pod is unready, someone may bypass the Service and access it directly:

curl http://<pod-ip>:8080

This is not blocked by readiness logic.

5. DaemonSet Without Readiness Probe

DaemonSet Pods (like logging agents) usually don’t have readiness probes.

If they’re part of a Service accidentally, they might receive traffic regardless of their state.

5. How to Prevent Unready Pods from Getting Traffic

1. Always Define Readiness Probes

Use appropriate probes (HTTP, TCP, or exec) that truly reflect application readiness.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

2. Use Startup Probes (for long boot apps)

A startup probe delays the readiness probe until the app finishes initialization.

startupProbe:
  httpGet:
    path: /start
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

This ensures that readiness probe only starts after startup is successful.

3. Test and Simulate Traffic

Use kubectl port-forward and tools like curl to simulate traffic before exposing to users.

4. Graceful Rollouts

Use RollingUpdate strategy to gradually replace Pods. Ensure readiness is checked during rollout.

5. Health Checks in Services like Istio or NGINX

Ensure that service mesh or ingress controllers respect Kubernetes readiness status before routing.