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