From the official documentation:
Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.
In this documentation, you will find a very good rolling update overview:
Rolling updates allow the following actions:
- Promote an application from one environment to another (via container image updates)
- Rollback to previous versions
- Continuous Integration and Continuous Delivery of applications with zero downtime
Here you can find information about Rolling update deployment:
The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate
. You can specify maxUnavailable
and maxSurge
to control the rolling update process.
Additionally, you can add another 2 fields: Max Unavailable and Max Surge.
.spec.strategy.rollingUpdate.maxUnavailable
is an optional field that specifies the maximum number of Pods that can be unavailable during the update process.
.spec.strategy.rollingUpdate.maxSurge
is an optional field that specifies the maximum number of Pods that can be created over the desired number of Pods.
Now it's up to you how you set these values. Here are some options:
- Deploy by adding a Pod, then remove an old one:
maxSurge
= 1, maxUnavailable
= 0. With this configuration, Kubernetes will spin up an additional Pod, then stop an “old” one down.
- Deploy by removing a Pod, then add a new one:
maxSurge
= 0, maxUnavailable
= 1. In that case, Kubernetes will first stop a Pod before starting up a new one.
- Deploy by updating pods as fast as possible:
maxSurge
= 1, maxUnavailable
= 1. This configuration drastically reduce the time needed to switch between application versions, but combines the cons from both the previous ones.
See also: