Rolling Update vs Recreate

Two deployment strategies. When to use each.

RollingUpdate

RollingUpdate and Recreate are the two Deployment update strategies. Rolling is the default; Recreate is a last resort. The discipline is using each appropriately; defaulting to rolling produces good outcomes.

What RollingUpdate provides:

• Default.: RollingUpdate is the Kubernetes default. New Deployments use it without configuration; the discipline is built in; the team gets it for free.
• Replace pods one at a time.: The strategy replaces pods incrementally. Old pods terminate; new pods start; the workload is updated gradually.
• Zero downtime.: If the application supports it (graceful shutdown, multiple replicas), rolling updates produce zero downtime. The replicas are always sufficient to serve traffic.
• Slow.: The trade-off is speed. Rolling updates take time; the duration is proportional to replica count and the rollout's pace; faster pace means faster rollouts but more disruption.
• maxSurge and maxUnavailable.: The parameters control the rollout pace. maxSurge allows extra pods during rollout; maxUnavailable allows temporary capacity reduction. Tuning balances speed and stability.

RollingUpdate is the right default. The zero-downtime characteristic matches most workloads' needs.

Recreate

Recreate is the alternative. All old pods terminate; then new pods start. The strategy is fast but causes outage.

• All down; all up.: The Recreate strategy stops all old pods first; then starts all new pods. There is a moment where no pods are running.
• Fast but causes outage.: The strategy is faster than rolling but produces outage. The duration of the outage is the time to start new pods; users see the disruption.
• Use only when rolling cannot work.: Most workloads do not need Recreate. The discipline is using it only when rolling truly cannot work; the default is rolling.
• Document the choice.: When Recreate is used, the choice is documented. Future maintainers see why; the choice is preserved through team changes.
• Schedule during low-traffic.: Recreate updates should be scheduled during low-traffic windows. The outage's customer impact is bounded; the disruption is acceptable.

Recreate is the special case. Most updates use rolling; Recreate is reserved for specific needs.

When recreate

The when-to-use Recreate is narrow. Stateful migrations that cannot have mixed versions are the typical case; everything else uses rolling.

• Stateful migrations that cannot have mixed versions.: Some upgrades are incompatible across versions. Old and new pods cannot coexist; the schema or protocol changes break compatibility; Recreate ensures only one version exists at any moment.
• Rare.: Most upgrades support mixed versions. Modern applications are designed for compatibility; rolling updates work; Recreate is rarely needed.
• Default to rolling.: The team's discipline is rolling updates. Recreate is the exception; the exceptions are documented; the default is preserved.
• Database migrations sometimes need Recreate.: Some database schema changes are incompatible. Recreate ensures the application restarts cleanly with the new schema; mixed-version reads are avoided.
• Single-replica workloads.: Single-replica workloads have outage during update regardless. Recreate is no worse than rolling; the simpler strategy may be appropriate.

Rolling update vs recreate is one of those Kubernetes deployment choices that defaults to the better option. Nova AI Ops integrates with cluster deployment telemetry, surfaces patterns, and supports the team's deployment discipline.