Applying a rolling update strategy

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
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 99%
maxSurge
The maxSurge parameter defines how many extra pods can be added to the set number of replicas during an update. The maxSurge parameter allows Red Hat OpenShift to create new pods before it deletes old ones to maximize availability. The value can be a number or a percentage. For example, if maxSurge 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.
maxUnavailable
The maxUnavailable parameter defines the maximum number of old pods that are allowed to be down during an update. By default, OpenShift removes 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 maxUnavailable 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.
Important: The maxUnavailable option is a feature gate for Kubernetes StatefulSet components. A feature gate is designed so that an administrator can enable or disable the specific Kubernetes feature on your OpenShift cluster. For more information, see Enabling features using feature gates External link opens a new window or tab. If the feature is not enabled on the cluster, the feature is not used. To enable the maxUnavailable feature for StatefulSet components on your cluster, run the following command from the Red Hat OpenShift Container Platform infrastructure node.
oc patch featuregate cluster --type=merge \
-p '{"spec": {"featureSet": "CustomNoUpgrade", "customNoUpgrade": {"enabled": ["MaxUnavailableStatefulSet"]}}}'

When the MaxUnavailableStatefulSet feature is enabled on the cluster, the rolling_update.max_unavailable parameters in the CP4BA custom resource for StatefulSet components are considered.

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), maxSurge is set to 1, and maxUnavailable is set to 25%.

Procedure

  1. When an update is triggered, 1 new pod is created (F) as a result of the maxSurge 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 maxUnavailable set to 1. maxUnavailable 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. OpenShift waits for pod G to become ready, then removes pod B.
    2. A new pod H is added. OpenShift waits for pod H to become ready, then removes pod C.
    3. A new pod I is added. OpenShift waits for pod I to become ready, then removes pod D.
    4. A new pod J is added. OpenShift waits 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.