Kubernetes rolling updates replace pods gradually

Sat, 27 Nov 2027 00:00:00 +0000

Choose the release shape before its speed. Can old and new versions process requests together? Can they share storage and ownership safely? What happens if the new version cannot start? Those answers determine whether a Deployment should overlap versions with RollingUpdate or stop the old version before replacement with Recreate. The companion article handles rollout pacing and live observation.

Choose version overlap only after compatibility and ownership checks. Recreate changes upgrade ordering; rollback still needs a tested image, configuration and data recovery plan.

Replace gradually or stop first

RollingUpdate is the default Deployment strategy. Its surge and unavailable budgets control replacement while allowing old and new ReplicaSets to coexist. Readiness contributes to availability accounting, but does not establish application correctness or guarantee that every request succeeds.

Recreate waits for old Pods to terminate during a Deployment upgrade before creating the new version. Plan an interval with no serving replicas. Remove the rollingUpdate configuration when selecting this strategy; those fields belong only to RollingUpdate. Measure shutdown and startup rather than assuming a thirty-second window.

Compatibility is the deciding constraint

Overlap requires compatible APIs, stored data, and background work. A frontend can look healthy while an old worker misreads records written by the new worker. Test mixed-version reads and writes, job ownership, and retry behavior before adjusting replica counts. A rollout budget cannot repair an incompatible schema change.

Stateful does not automatically mean Recreate: a properly coordinated replicated application may support overlapping versions. Conversely, Recreate is not a distributed lock. Its ordering applies to Deployment upgrades; a ReplicaSet may replace a manually deleted Pod while that Pod is still terminating. Singleton correctness needs application coordination and, where required, fencing that prevents an obsolete owner from writing.

Storage terminology also matters. ReadWriteOnce restricts writable mounting to one node, not necessarily one Pod. Multiple Pods on that node may access the volume. ReadWriteOncePod provides single-Pod access for supported CSI volumes. Check the actual driver and workload requirements rather than using a storage label as proof of exclusive ownership.

Rollback is another change

Keep a restartable previous image and revision history. kubectl rollout undo restores a recorded Pod template; changing only the image may miss changed arguments or environment references. Neither operation reverses a database migration or restores the contents of an independently edited ConfigMap. An old template referencing the same ConfigMap name can still receive new data.

Before release, record which image, configuration, and data versions work together. Prefer backward-compatible migrations when overlap or rollback is required. Rehearse the recovery sequence and its downtime; retaining a ReplicaSet alone does not make that sequence safe. With Recreate, returning to the old version can entail another stop/start interval.

When it breaks

Uncoordinated workers can duplicate jobs or corrupt data while every Pod is Ready. Investigate ownership and compatibility, not only container health. A slow image pull or storage attachment can stretch a Recreate outage long beyond the measured application startup time. Include a genuinely cold start and shutdown tail in the rehearsal.

For four replicas, maxUnavailable: 50% permits a reduction to two available replicas, not automatically one. A failed replacement can stall progress; an independent failure can reduce capacity further. Determine whether two instances can carry the expected load before accepting that budget.

A zero unavailable budget still cannot prevent unrelated failures. At the other extreme, allowing the whole replica count to be unavailable is legal, although often undesirable. Treat rejecting that setting as an organizational policy, not a Kubernetes API rule. Both surge and unavailable cannot be zero.

Check it quickly

Save this as strategy_window.py and run python3 strategy_window.py. This standard-library model accepts positive replica counts and nonnegative integer budgets only. It calculates planning quantities, not a controller simulation or a complete API validator. A scaled-to-zero Deployment is legal Kubernetes state, deliberately outside this active-rollout exercise.

"""Integer rollout-budget arithmetic; no cluster or traffic is exercised."""


def rolling_budget(replicas, surge, unavailable):
 values = (replicas, surge, unavailable)
 if any(type(value) is not int for value in values):
 raise ValueError("this model accepts integers only")
 if replicas <= 0 or surge < 0 or unavailable < 0:
 raise ValueError("positive replicas and nonnegative budgets required")
 if surge == 0 and unavailable == 0:
 raise ValueError("surge and unavailable cannot both be zero")
 planned_floor = max(0, replicas - unavailable)
 target_ceiling = replicas + surge
 return planned_floor, target_ceiling


def main():
 assert rolling_budget(6, 1, 1) == (5, 7)
 assert rolling_budget(4, 0, 2) == (2, 4)
 assert rolling_budget(4, 1, 4) == (0, 5)
 for invalid in [(4, 0, 0), (4, -1, 1), (0, 1, 0)]:
 try:
 rolling_budget(*invalid)
 except ValueError:
 pass
 else:
 raise AssertionError(f"invalid model input accepted: {invalid}")
 print("rolling: planned availability floor=5, replica target ceiling=7")
 print("full-unavailability budget: planned floor=0 (permitted)")
 print("recreate: expect a zero-serving interval during replacement")
 print("PASS: budget arithmetic only; runtime availability untested")


if __name__ == "__main__":
 main()

Expect four output lines ending in the arithmetic-only PASS message. Six/one/one yields five and seven; the full-unavailability case deliberately yields zero. Terminating Pods, independent failures, scheduling, and request handling are outside the model, so neither number is an observed runtime bound.

The assertions were executed with Python 3.12.14 in Linux during this revision. No Kubernetes integration exercise was executed. Before adopting the strategy, rehearse an upgrade and rollback in staging with continuous requests, storage checks, and mixed-version business tests. Record their results separately from this local arithmetic check.

Sources

Kubernetes Deployments, upgrade ordering and revision rollback, checked 2026-10-15.
Deployment API, strategy fields and rollout budgets, checked 2026-10-15.
Kubernetes persistent volumes, node-level and Pod-level access modes, checked 2026-10-15.
Kubernetes ConfigMaps, configuration references and propagation, checked 2026-10-15.
Kubernetes StatefulSet deletion considerations, identity and duplicate-process risks, checked 2026-10-15.

Deploy · XB Field Notes