Full lesson
Explore the full explanation, examples, and visuals at your own pace.
3 replicas, 1 broken
One in three checkout requests is failing, and it's not random. Three Pods sit behind a Service: pod-a, pod-b, and pod-c. Pod-c's process is running, but its database connection pool is broken, so it returns 500 errors while the others answer fine.
Endpoints include every Ready Pod
The Service doesn't talk to Pods directly. It routes through its EndpointSlice, which lists every Pod that's Ready. With no readinessProbe, a running container counts as Ready, so pod-c sits in that list right next to pod-a and pod-b.
deployment.yaml (before)
The Deployment asks for three replicas, and the app: checkout label is how the Service finds them. But look at the end of the container spec. There's no readinessProbe, so Kubernetes knows the process started, yet never asks whether checkout can actually serve requests.
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout
spec:
replicas: 3
selector:
matchLabels:
app: checkout
template:
metadata:
labels:
app: checkout
spec:
containers:
- name: checkout
image: shop/checkout:1.4
ports:
- containerPort: 8080
# no readinessProbeA slow failure spreads upstream
A hanging Pod is worse than a dead one. The Service routes a checkout to pod-c, and the frontend waits, holding a thread until the timeout. Then it retries, and pod-a answers 200 OK. The request succeeds, but it's slow, and every retry adds load.
deployment.yaml (fix)
The fix is a readinessProbe on the checkout container. The kubelet calls /ready on port 8080 every five seconds. After three failures, about fifteen seconds, it marks the Pod NotReady. So /ready should check that this Pod can actually serve requests.
containers:
- name: checkout
image: shop/checkout:1.4
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 3With the new probe, pod-c's /ready check fails three times in a row. What does Kubernetes do?
With the new probe, pod-c's /ready check fails three times in a row. What does Kubernetes do?
- Restarts pod-c's container immediately
- Removes pod-c from the Service endpoints
- Creates a fourth replica to replace pod-c
With the new probe, pod-c's /ready check fails three times in a row. What does Kubernetes do?
Removes pod-c from the Service endpoints. A failing readiness probe only changes routing. Kubernetes marks pod-c NotReady, and the EndpointSlice stops listing it, so the Service skips it. Restarting is the liveness probe's job, and the Deployment still counts pod-c as one of its three replicas.
- Restarts pod-c's container immediately
- Removes pod-c from the Service endpoints
- Creates a fourth replica to replace pod-c
pod-c out of rotation
Now the Service routes through the EndpointSlice, and that list only includes pod-a and pod-b. Pod-c is marked NotReady and dropped. New requests stop reaching it, so the errors stop, and two healthy replicas absorb the traffic.
Readiness probe limits
Readiness only stops traffic. pod-c stays broken, and requests still fail for about fifteen seconds first. Don't point the check at a shared database, or every Pod can go unready together. Restarting is liveness's job.
- Readiness stops traffic; liveness restarts containers
- Checking a shared DB can unready all Pods
- Probe timing sets the failure window
Replicas help only if routing sees health
A Service sends traffic to every Pod that's Ready, healthy or not. Three replicas only protect you if routing can tell the difference. So write a readinessProbe that makes Ready mean this Pod can actually serve requests.