Choosing Between RollingUpdate and Recreate Deployments in OpenShift

The decision and your constraints

You need to deploy a new version of an application on Red Hat OpenShift Container Platform without breaking users or shared data. OpenShift Deployments support two update strategies, and the wrong choice can either cause downtime or let incompatible versions run at the same time.

Use this decision:

• RollingUpdate for stateless workloads that can run two versions side by side.
• Recreate when old and new versions cannot coexist, such as stateful services or backward-incompatible database schema changes.

A Deployment manages ReplicaSets, which in turn run pods. A readiness probe tells OpenShift when a container is ready to receive traffic.

Supported strategies compared

Strategy	Behavior	Availability during update	Best suited for	Main risk
RollingUpdate	Replaces pods incrementally using maxSurge and maxUnavailable.	Maintains a minimum number of available pods.	Stateless APIs, web frontends, worker queues.	Old and new versions run together; incompatible database changes can fail.
Recreate	Stops all old pods before starting new ones.	Brief user-facing downtime.	Stateful workloads, single-replica legacy apps, incompatible schema changes.	Downtime while old pods terminate and new pods start.

maxSurge is the maximum number of pods above the desired count that OpenShift may create during a RollingUpdate. maxUnavailable is the maximum number of pods that may be unavailable during the update.

Trade-offs that determine the choice

• Side-by-side execution. RollingUpdate can briefly serve traffic from both versions. If your new code writes to a database table that the old code cannot read, or drops a column the old code still uses, the overlap causes errors.
• Downtime tolerance. Recreate stops every old pod before creating replacements. Even with multiple replicas, all pods are terminated, so users experience an outage until new pods pass readiness checks.
• Readiness probes. Without a readiness probe, OpenShift considers a container ready as soon as it starts. A missing or misconfigured probe can send traffic to unhealthy pods or make a rollout appear complete before the application is actually serving requests.

Change the strategy on a Deployment

Run these commands from a terminal with the OpenShift CLI (oc) installed and authenticated to the cluster. You need update permission on deployments.apps in the target namespace, typically granted by the edit or admin role in that project.

This example changes a Deployment named api-backend in namespace production to Recreate:

oc patch deployment api-backend -n production --type merge -p '{"spec":{"strategy":{"type":"Recreate"}}}'

Expected check:

oc get deployment api-backend -n production -o yaml | grep -A 6 'strategy:'

Confirm the output shows type: Recreate. Changing spec.strategy.type affects future rollouts only; existing ReplicaSets keep the strategy they were created with.

Risk: Recreate causes downtime during the update window. If the Deployment has a Pod Disruption Budget, ensure the termination window for Recreate does not conflict with it.

Trigger and validate a rollout

After changing the strategy, roll out a new image to verify the behavior:

oc set image deployment/api-backend backend=registry.example.com/api-backend:v2 -n production
oc rollout status deployment/api-backend -n production

The status command blocks until the rollout completes or fails. For RollingUpdate, watch for new pods being created while old pods remain within the maxUnavailable limit. For Recreate, confirm old pods terminate before new ones start.

Inspect history and roll back a bad rollout if needed:

oc rollout history deployment/api-backend -n production
oc rollout undo deployment/api-backend -n production

oc rollout undo reverts a rollout, such as a bad image. It does not change spec.strategy.type. To return to RollingUpdate, patch the strategy field again.

Limitations and pre-flight checks

• Strategy changes do not modify existing ReplicaSets.
• Recreate terminates all replicas, so multi-replica Deployments still experience downtime.
• RollingUpdate requires working readiness probes; otherwise unhealthy pods may receive traffic.
• Pod Disruption Budgets can block a RollingUpdate if the budget would be violated.

Practical verification: run oc get deployment <name> -n <namespace> -o yaml and confirm spec.strategy.type matches your decision, then run oc rollout status deployment/<name> -n <namespace> after the next rollout.