Kubernetes 101 : Deployments and Rolling updates - maxSurge, maxUnavailable -



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:


Remark:

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
  • maxUnavailable: maximum number of pods allowed to be stopped to be replaced by updated ones.
Remark:

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 - we can have a maximum of four old and updated pods running in parallel -.
  • maxUnavailable: two (2) pods.
Remark:

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 podsif it is not a natural number.

Checking the "rollout" status:

We can check the "rollout" status of our deployment using the below command:


Comments

Leave as a comment:

Archive