Applying a rolling update strategy

Edit online

 25.0.1.0 
 A rolling update gradually replaces the old pods of a deployment with new ones, which keeps as many pods alive as possible to avoid downtime. A rolling update is triggered when any change is made to an application, including the container image, environment variables, ports, config, or any change to the custom resource.

About this task

A rolling update strategy uses two parameters:

spec:
  strategy:
    type: RollingUpdate
    rolling_update:
      max_surge: "1"
      max_unavailable: "99%"
max_surge
The max_surge parameter defines how many extra pods can be added to the set number of replicas during an update. The max_surge parameter allows Kubernetes clusters to create new pods before it deletes old ones to maximize availability. The value can be a number or a percentage. For example, if max_surge is set to 1, then up to 1 extra pod can be created temporarily during a rolling update. If the value of the replicas parameter is set to 2, then the maximum number of pods is 3.
max_unavailable
The max_unavailable parameter defines the maximum number of old pods that are allowed to be down during an update. By default, Kubernetes clusters remove one pod at a time as it creates new pods, which makes sure that the set replicas count is maintained. The value can be a number or a percentage. For example, if the value of max_unavailable is set to 99% and the number of replicas is set to 2, then 99% of 2 is 1.98. The value 1.98 is rounded down to 1, so 1 pod can be taken offline during the update.

The following steps explain how a rolling update strategy works. For the example, the replicas parameter is set to 5 (the 5 running pods are named A, B, C, D, E), max_surge is set to 1, and max_unavailable is set to 25%.

Procedure

  1. When an update is triggered, 1 new pod is created (F) as a result of the max_surge value of 1.

    The system waits for the pod to be created and passes the health check. The readiness probe indicates that the pod is "Ready".

  2. One of the old pods is then deleted.

    Removing one pod respects the max_unavailable set to 1. max_unavailable is set to 25%, which is 1.25 pod in this case, and 1.25 is rounded down to 1.

    For the sake of simplicity, pod A is removed, but the selection for removal is unpredictable.

  3. The replacement of pods is then repeated for all the other pods (B, C, D, E).
    1. A new pod G is added. Kubernetes clusters wait for pod G to become ready, then removes pod B.
    2. A new pod H is added. Kubernetes clusters wait for pod H to become ready, then removes pod C.
    3. A new pod I is added. Kubernetes clusters wait for pod I to become ready, then removes pod D.
    4. A new pod J is added. Kubernetes clusters wait for pod J to become ready, then removes pod E.
  4. When the update is complete, all the old pods are deleted and all the new pods (F, G, H, I, J) are running.