10.6 Kubernetes Deployment Rollout Control

Kubernetes Deployment Rollout Control is the set of fields, strategies, and operational commands that govern precisely how a Deployment transitions Pods from an old version to a new version, giving operators fine-grained control over the pace, safety margins, and reversibility of updates rather than leaving the transition to an implicit or uncontrolled process.

Update Strategy Types

RollingUpdate Strategy

The RollingUpdate strategy, which is the default, gradually replaces old Pods with new ones according to configured surge and unavailability tolerances, allowing the application to remain continuously available throughout the update by never taking down more capacity than the configured tolerances allow at any given moment.

Recreate Strategy

The Recreate strategy takes a simpler but more disruptive approach, terminating all existing Pods before creating any new ones, resulting in a period of complete unavailability during the transition, which is sometimes necessary for applications that cannot tolerate two versions running simultaneously, such as those relying on exclusive access to a shared resource.

Surge and Unavailability Controls

maxSurge

The maxSurge field, expressible as either an absolute number or a percentage of the desired replica count, defines how many additional Pods beyond the desired count can exist temporarily during a rollout, allowing new Pods to be created and become ready before old Pods are removed, minimizing capacity dips.

maxUnavailable

The maxUnavailable field defines how many Pods below the desired count are tolerated during the rollout, allowing old Pods to be removed before all new replacements are fully ready, which can speed up rollouts at the cost of temporarily reduced capacity, and is often tuned in combination with maxSurge to balance speed against availability.

Progress Deadline and Failure Detection

progressDeadlineSeconds

The progressDeadlineSeconds field specifies how long the Deployment controller waits for visible progress, such as new Pods becoming ready, before considering the rollout stalled and marking the Deployment's Progressing condition as failed, providing an automated signal that something is preventing the rollout from advancing.

Distinguishing Stalled From Slow Rollouts

A rollout exceeding its progress deadline does not automatically roll back; it simply surfaces a failure condition for visibility, leaving the decision of whether to intervene, wait longer, or roll back entirely in the hands of the operator or an external automation system monitoring Deployment status.

Pausing and Resuming Rollouts

Deliberate Rollout Suspension

Pausing a Deployment halts the rollout controller from making further progress on an in-flight update, which is useful for inspecting the state of a partially rolled out change or for batching multiple template modifications together before allowing the rollout to proceed as a single combined update.

Resuming Halted Progress

Resuming a paused Deployment allows the rollout controller to continue reconciling toward the fully updated state, picking up exactly where it left off rather than restarting the rollout from the beginning, since the underlying ReplicaSet scaling state was preserved throughout the pause.

Rollback Operations

Reverting to a Previous Revision

Rolling back a Deployment reapplies a previous revision's Pod template as the new desired template, triggering the same rolling update mechanics used for any forward update, but directed toward restoring a prior known-good configuration rather than introducing a new one.

Revision History as the Basis for Rollback

The revisionHistoryLimit field controls how many old ReplicaSets, and therefore how many distinct rollback targets, are retained, with each retained ReplicaSet corresponding to a specific point in the Deployment's update history that remains available for potential future rollback.

Minimum Readiness Enforcement

minReadySeconds

The minReadySeconds field requires a newly created Pod to remain in the ready state for a specified duration before it is considered available for the purposes of rollout progress calculations, guarding against counting a Pod as successfully rolled out based on a brief, possibly unstable moment of readiness.