Deployments and rolling updates:
Deployments manage replicaSets and replicaSets in turn manage pods.
Using deployments we could launch a "rollout", that would specify how an application's upgrade is done on the running pods.
Below is an example of a deployment "rollout" strategy:
A rollout occurs when we modify elements in the pod section above. We can then apply the changes using the below command:
The "Strategy" specifies the type of the update, which could have either a "RollingUpdate" or "Recreate" strategy.
With the "Recreate" method, all the pods will get deleted, and the "updated" ones will replace them.
Using the "RollingUpdate" strategy, a deployment will stop a pod, update it, redeploy it, then check if its in a "Ready" state before moving on to the next pod.
- maxSurge: maximum number of newly created pods beyond the "desired state" number of pods " replicas: 3 in our above example".
- maxUnavailable: maximum number of pods allowed to be stopped to be updated.
The default value for both the maxSurge and the maxUnavailable is 25%.
For the below diagram, we have for example the below maxSurge and maxUnavailable values :
- maxSurge: one (1) pod.
- maxUnavailable: two (2) pods.
We can either specify a percentage value or a number of pods for both values ( maxSurge, maxUnavailable ).
When we use a percentage for the ( maxSurge, maxUnavailable ) values, kubernetes will round up the number of pods, if it is not a natural number.
Checking the "rollout" status:
We can check the "rollout" status of our deployment using the below command: