A rolling deploy runs old and new versions side by side for a short time by design. Minutes are normal. A mix that persists for hours or days is drift, caused by a stuck rollout, pinned nodes, or cached images, and it means the dependencies you scanned are not the only ones running.
What a rolling update does
The Kubernetes Deployment documentation describes the process: a new ReplicaSet is created and scaled up while the old one is scaled down, so pods are replaced at a controlled rate. In the documentation's example, the end state is three available replicas in the new ReplicaSet and the old one scaled to zero. It also notes that Kubernetes does not count terminating pods when calculating available replicas.
During the middle of that process, both versions serve traffic. That is expected, and your application has to tolerate it.
When a mix becomes drift
| Observation | Likely meaning |
|---|---|
| Old and new pods for a few minutes | Normal rollout |
| Rollout paused or failing, old pods still serving | Stuck deploy |
| New pods crash looping, old ones kept alive | Failed release hiding behind healthy old pods |
| Same deployment, different image content on different nodes | Tag moved or cache served an older image |
| Old ReplicaSet scaled above zero long after rollout | Manual scaling or a stale autoscaler setting |
The documentation also warns that if pods are crash looping and rollouts keep being triggered, a Deployment may never reach a complete state. A half finished rollout looks like success in a quick check.
What to check after every deploy
- Read the image identifier of every running pod, and confirm only the new digest appears.
- Confirm the old ReplicaSet has zero replicas.
- Check that rollout status reports complete, not just started.
- If you use canaries on purpose, record the intended split and an end time.
Security angle
If the old version has a known vulnerability, every minute it runs matters, and a stuck rollout leaves it serving users. Alert when a rollout exceeds its expected duration. Also remember that two versions share a database, queue, or cache, so compatibility problems can look like security incidents.
Reducing mixed state
- Reference images by digest, so nodes cannot pull different content under one tag. See tag or digest.
- Set a progress deadline and alert on it.
- Keep rollout history so you can compare versions.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how monitoring reports state over time. A post deploy check works the same way: compare what runs now with what you approved.
What Safeguard does here
Safeguard scans container images and monitors them, so you can see which image versions carry which findings. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a canary release drift?
Not if it is intentional, has an owner, and ends on a schedule. Unplanned splits are drift.
How long is too long?
Longer than your usual rollout time plus a margin. Set the threshold from your own history.
Sources
Last reviewed: 19 October 2026.
