A rolling deployment gradually REPLACES INSTANCES of an application's prior version with instances of the new version. If no deployment strategy is given on a DeploymentConfig object, the rolling strategy is utilised by default.

Before scaling down the old COMPONENTS, a rolling deployment normally waits for fresh pods to become ready via a readiness check. If a major problem arises, the rolling deployment can be stopped.

The rolling deployment should be used:

• When you don't want to experience any downtime while updating an application.
• When your application allows you to run both old and new code at the same time.

You can have both old and new VERSIONS of your code running at the same time with a rolling deployment. This usually necessitates your application's ability to handle N-1 compatibility.

The rolling strategy supports the following:

• Any pre-LIFECYCLE hook is executed.
• Based on the surge count, scales up the new replication controller.
• The previous replication controller is scaled down according to the maximum unavailability count.
• Scales the new replication controller until it reaches the target replica count and the old replication controller is scaled to zero.
• Any post lifecycle hook is executed.