# How Load Balancers Route Traffic During Kubernetes Rollouts When Pods Fail

> Learn how Kubernetes load balancers route traffic during rollouts, excluding failed pods and ensuring service availability. Discover seamless updates with expert insights.

- Repository: [Anil Kumar/DevOps-Interview-Guide](https://github.com/litu54/DevOps-Interview-Guide)
- Tags: how-to-guide
- Published: 2026-08-10

---

**During Kubernetes rolling updates, load balancers route traffic exclusively to Pods with a Ready status, automatically excluding failed or crash-looping Pods from the Service endpoints list.**

When deploying applications to Kubernetes clusters, maintaining traffic availability during rolling updates requires understanding how the Service endpoint controller interacts with Pod health states. According to the `litu54/DevOps-Interview-Guide` repository—specifically the JPMorgan DevOps SRE interview questions—this mechanism ensures that traffic never reaches unstable replicas even when deployments fail mid-rollout. The system automatically manages traffic routing by monitoring readiness probes and dynamically updating endpoint lists based on Pod status.

## Readiness Probes Control Traffic Routing

The Kubernetes Service load balancer—whether an external cloud provider load balancer or internal `kube-proxy`—forwards traffic only to Pods that report a **Ready** status. This behavior is not automatic based on Pod existence; it requires explicit health validation through the `readinessProbe` configuration.

### Endpoint Controller and Pod Status

The endpoint controller continuously monitors the `readinessProbe` status of every Pod matching a Service's selector. In the scenario documented in [`JPMorgan/DevOps_SRE.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/JPMorgan/DevOps_SRE.md) (question 7), when a rolling update creates a new replica that enters `CrashLoopBackOff`, the Pod never achieves Ready status. Consequently, the endpoint controller **never adds** the Pod's IP address to the Service's Endpoints list.

- **Ready Pods**: Added to the Endpoints list and receive traffic
- **NotReady Pods**: Excluded from the Endpoints list and receive no traffic  
- **CrashLoopBackOff Pods**: Remain in NotReady state, completely isolated from traffic

## RollingUpdate Strategy and Traffic Isolation

The default `RollingUpdate` deployment strategy creates new replicas before terminating old ones, but traffic routing depends entirely on readiness state transitions rather than Pod creation order.

### Traffic Routing During Pod Failure

When a new Pod fails during rollout, the following sequence occurs:

1. The deployment controller creates the new replica
2. The new Pod crashes or fails its `readinessProbe`
3. The endpoint controller excludes the failed Pod from the Service
4. The load balancer continues routing **only** to the existing healthy Pods
5. The rollout pauses until the new Pod recovers or the deployment is aborted

This means in the specific interview scenario with two replicas where the second Pod enters `CrashLoopBackOff`, the load balancer routes traffic exclusively to the first, healthy Pod—the old replica that remains in the Ready state.

### Configuration Parameters

The `maxUnavailable` and `maxSurge` settings in the Deployment spec determine how many Pods can be unavailable or created above the desired count during updates:

```yaml
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0      # Ensure zero downtime; all old Pods stay Ready

      maxSurge: 1            # Create one extra Pod during update

```

Setting `maxUnavailable: 0` guarantees that the load balancer always has healthy endpoints to route to, even when new Pods fail.

## Practical Implementation and Verification

To observe this behavior in a live cluster, configure a Deployment with explicit readiness probes:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: myrepo/my-app:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

```

Trigger an update and monitor endpoint changes:

```bash

# Initiate rolling update

kubectl set image deployment/my-app app=myrepo/my-app:v2

# Watch endpoint slices to see which Pods receive traffic

kubectl get endpointslices -l kubernetes.io/service-name=my-app -w

```

If the new Pod image is faulty and crashes, the endpoint slice will show only the old Pod's IP addresses, confirming that the load balancer routes traffic exclusively to the healthy replica.

## Summary

- Load balancers route traffic exclusively to Pods with Ready status, managed through the Service Endpoints list
- Pods in `CrashLoopBackOff` or failing readiness probes are automatically excluded from endpoint lists
- During rolling updates, the load balancer continues serving traffic to old healthy Pods while new failed Pods are isolated
- Setting `maxUnavailable: 0` ensures traffic capacity is maintained even when new Pods fail
- This behavior is documented in the interview questions at [`JPMorgan/DevOps_SRE.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/JPMorgan/DevOps_SRE.md) in the DevOps-Interview-Guide repository

## Frequently Asked Questions

### What happens if a new Pod passes liveness but fails readiness during a rollout?

The load balancer will **not** route traffic to the Pod. Liveness probes only determine if a container should be restarted; readiness probes control traffic routing. A Pod can be alive (running) but not ready (serving traffic), in which case it remains excluded from the Service endpoints until the readiness probe succeeds.

### Can a load balancer accidentally route traffic to a crashing Pod?

No. The endpoint controller removes a Pod's IP address from the Service endpoints immediately when the readiness probe fails or the container crashes. This update happens before the load balancer's next sync cycle, ensuring traffic never reaches Pods that are not explicitly Ready.

### How does maxUnavailable affect traffic during failed rollouts?

Setting `maxUnavailable: 0` (as shown in the configuration examples from the repository) ensures Kubernetes never terminates old Pods until new Pods are Ready. If new Pods fail, the old Pods remain in the Endpoints list, maintaining 100% traffic capacity. Conversely, allowing `maxUnavailable: 1` would remove an old Pod before confirming the new one is healthy, potentially reducing capacity.

### Where is the original interview question documented?

The specific scenario regarding two replicas with one entering `CrashLoopBackOff` is documented in [`JPMorgan/DevOps_SRE.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/JPMorgan/DevOps_SRE.md) at line 13 within the `litu54/DevOps-Interview-Guide` repository. This file contains the complete question and context regarding how load balancers handle traffic routing during Kubernetes rolling updates.