MiddleDebuggingOccasionalNot answered yet

A rolling update is stuck at 2 of 5 updated replicas and new Pods never go Ready — diagnose it.

A rollout has not progressed for minutes. Below is what you see. Explain why it is stuck (given maxUnavailable is small) and how you fix it — without just deleting the probe or scaling up.

$ kubectl rollout status deploy/api
Waiting for deployment "api" rollout to finish: 2 out of 5 new replicas updated...

$ kubectl get pods -l app=api
NAME             READY   STATUS    RESTARTS   AGE
api-7d9c-aaaa    0/1     Running   0          4m
api-7d9c-bbbb    0/1     Running   0          4m
api-5f8b-cccc    1/1     Running   0          2d

$ kubectl describe pod api-7d9c-aaaa
Readiness probe failed: HTTP probe failed with statuscode: 503
Get "http://10.1.2.3:8080/ready": dial context ... connection refused

Give the diagnosis and the fix.

The new Pods are Running but 0/1 Ready because their readiness probe returns 503, so the Deployment won't retire more old Pods — maxUnavailable bounds the roll and it stalls. Fix the real readiness cause (a dependency, wrong path/port, or short delay), not the replica count. If the app is only slow to warm up, add a startupProbe.

✗Raising replicas or resources instead of fixing the readiness failure
✗Deleting the readiness probe to force the roll to finish
✗Confusing a failing readiness probe with an image-pull error

→When is the right fix a startupProbe versus a longer initialDelaySeconds?
→How does maxUnavailable: 0 change the behaviour of this stalled roll?

Solution

The symptom is not a crash but a stalled rollout: old Pods are alive (1/1), new ones Running but 0/1 Ready.

connection refused on /ready. The new Pods are not Ready, so the Deployment is not allowed to retire more old Pods — maxUnavailable protects availability, and the roll freezes by design.

Read the cause: describe shows Readiness probe failed ... 503 and
Fix the real readiness cause, not the replica count:

a dependency (DB, config) is unreachable, so the endpoint honestly returns 503;
the probe path/port/scheme is wrong;
the app is simply slow to start and initialDelaySeconds is too small.

comes up), not "add more resources":

For a slow start use a startupProbe (it gates liveness/readiness while the app

startupProbe:
  httpGet: { path: /ready, port: 8080 }
  failureThreshold: 30
  periodSeconds: 5

If the new version is genuinely broken, kubectl rollout undo deploy/api.

Open topic in roadmap →

A rolling update is stuck at 2 of 5 updated replicas and new Pods never go Ready — diagnose it.

A rollout has not progressed for minutes. Below is what you see. Explain why it is stuck (given maxUnavailable is small) and how you fix it — without just deleting the probe or scaling up.

$ kubectl rollout status deploy/api
Waiting for deployment "api" rollout to finish: 2 out of 5 new replicas updated...

$ kubectl get pods -l app=api
NAME             READY   STATUS    RESTARTS   AGE
api-7d9c-aaaa    0/1     Running   0          4m
api-7d9c-bbbb    0/1     Running   0          4m
api-5f8b-cccc    1/1     Running   0          2d

$ kubectl describe pod api-7d9c-aaaa
Readiness probe failed: HTTP probe failed with statuscode: 503
Get "http://10.1.2.3:8080/ready": dial context ... connection refused

Give the diagnosis and the fix.

Solution

The symptom is not a crash but a stalled rollout: old Pods are alive (1/1), new ones Running but 0/1 Ready.

connection refused on /ready. The new Pods are not Ready, so the Deployment is not allowed to retire more old Pods — maxUnavailable protects availability, and the roll freezes by design.

Read the cause: describe shows Readiness probe failed ... 503 and

Fix the real readiness cause, not the replica count:

a dependency (DB, config) is unreachable, so the endpoint honestly returns 503;

the probe path/port/scheme is wrong;

the app is simply slow to start and initialDelaySeconds is too small.

comes up), not "add more resources":

For a slow start use a startupProbe (it gates liveness/readiness while the app

startupProbe: httpGet: { path: /ready, port: 8080 } failureThreshold: 30 periodSeconds: 5

If the new version is genuinely broken, kubectl rollout undo deploy/api.