rollout stuck with old and new pods: A rolling update stopped partway, leaving both versions serving

A stalled rollout leaves old and new ReplicaSets both non-zero. Traffic is split between versions until it resolves, which is usually the most urgent part of the problem.

Applies to: All Kubernetes versions

What it means

A rolling update replaces pods gradually, bounded by maxUnavailable and maxSurge. It stalls whenever the next step cannot be taken: new pods will not become Ready, or they cannot be created at all. While stalled, both ReplicaSets have running pods and the Service load-balances across both, so users get a mixture of the old and new version. That mixing is often the more pressing issue than the stall itself, particularly if the two versions disagree about an API contract or a database schema, and it is the reason a stalled rollout is worth resolving quickly rather than leaving to sort itself out.

Most common causes

• New pods failing a readiness probe, so the rollout will not proceed.
• New pods crash-looping on a bad image or configuration.
• New pods unschedulable because of resources, affinity, or taints.
• Quota preventing the surge pods a rolling update needs.
• maxUnavailable: 0 combined with a full cluster, so no new pod can be created before an old one is removed.
• A PodDisruptionBudget preventing old pods from being removed.

How to diagnose it

1. Check rollout status: kubectl rollout status deployment/DEPLOY --timeout=30s.
2. List the ReplicaSets and their replica counts: kubectl get rs -n NAMESPACE. Two non-zero sets confirm the split.
3. Describe a pod from the new ReplicaSet, which is where the error is.
4. If the new ReplicaSet has no pods at all, read its events for a creation rejection.
5. Check the rollout strategy's parameters against the cluster's available capacity.

How to fix it

1. Roll back if the new version is bad: kubectl rollout undo deployment/DEPLOY. This ends the version split immediately, which usually matters more than diagnosing in place.
2. Fix the new pods and let the rollout continue if the problem is external, such as a missing ConfigMap.
3. Set maxUnavailable: 0 so a failed rollout never reduces healthy capacity — the rollout stalls with the old version fully serving, which is the safer failure.
4. Free quota or capacity if surge pods cannot be created.
5. Use kubectl rollout pause deliberately while investigating, so the controller does not keep retrying underneath you.

Notes

maxUnavailable: 0 with maxSurge: 1 is the configuration that makes a failed rollout non-disruptive: the new pod is created first, and old pods are only removed once it is Ready. It needs one pod's worth of spare capacity, which is a small price for the property.

Related

• ProgressDeadlineExceeded — The rollout made no progress within its deadline
• Readiness probe failed — The pod was removed from service endpoints

Sources

• Kubernetes documentation — Deployments: rolling update
• Kubernetes documentation — ReplicaSet
• Kubernetes documentation — Disruptions