Kubernetes deployment strategies

2 min read | by Jordi Prats

To update a Deployment objects we can choose between two built-in strategies used to replace old Pods by new ones: Recreate and RollingUpdate

Let's see the differences between them

Deployment strategies can be configured using .spec.strategy.type, being RollingUpdate the default value


If we configure it to Recreate, all existing Pods are killed before new ones are created

This guarantees that if you upgrade a Deployment, all Pods of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new revision is created.

The principal advantage of using this strategy is that the it is guaranteed that the entire application state entirely renewed, at the cost of having downtime for upgrade operations. This downtime depends on both shutdown and boot duration of the application


By setting it to RollingUpdate, it will update Pods in a rolling update fashion. We can configure it's behaviour using the following variables (Both values can be an absolute number or a percentage of desired Pods):

  • maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. . The value cannot be 0 if MaxUnavailable is 0. The absolute number is calculated from the percentage by rounding up. The default value is 25%.

  • maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. It's value cannot be 0 if maxSurge is 0. The default value is 25%.

New verions are slowly released across instances, but we must take into account that rollout/rollback can take time

Posted on 04/08/2021