Rolling updates for ODM deployments

You can specify properties that control the rolling update of Operational Decision Manager components.

For each Operational Decision Manager deployment, you set up a rolling update by defining .spec.strategy.type==RollingUpdate. The deployment updates pods in a rolling update fashion, gradually scaling down the old ReplicaSets and scaling up the new one during an update procedure.

To control the rolling update process, you can specify maxUnavailable and maxSurge on each ODM components:

maxUnavailable: The maxUnavailable property determines the maximum number or percentage of pods that can be unavailable during a rolling update. By default, the value is set to 0.
maxSurge: The maxSurge controls the maximum number or percentage of pods that can be created over the desired number of pods. During an update, Kubernetes creates new pods to replace the old ones. The maxSurge property ensures that the total number of pods does not exceed a certain limit. By default, the value is set to 1.

With these settings, Kubernetes creates 1 additional pod at a time while keeping all existing pods running during the update. No pods are removed before the new pods are ready.

Here is an example of defining the parameters for Decision Center component in the values.yaml file:

decisionCenter:
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 1

With this configuration, Kubernetes launches up to two new pods above the desired count and permits one pod to be unavailable during the update. You can apply similar settings to other components, including decisionRunner, decisionServerConsole, and decisionServerRuntime.

Tuning

Improve the performance of the updating process:

Minimize downtime: To ensure zero downtime, leave maxUnavailable: 0. This forces Kubernetes to keep 100 percent of the pods running until new ones are ready, never dropping below full capacity. With this setting (and maxSurge ≥ 1), existing pods are only terminated after their replacements become available, avoiding service interruption.
Speed up updates: If you can tolerate a brief unavailability and want a faster rollout, increase maxSurge and/or maxUnavailable. For example, raising maxSurge to 2 and allowing maxUnavailable: 1 lets two new pods spin up in parallel and one old pod terminate during each step. This reduces the total upgrade time at the expense of a few pods being offline briefly.