Configuring a Component Upgrade Policy

In practice, component upgrade is a common scenario. Components deployed based on a container in ServiceStage support the following upgrade policies:

RollingUpdate: New pods are created gradually, and then old pods are deleted. This policy is used by default when you create and deploy a component based on a container, upgrade a component in rolling release mode, upgrade a component in dark launch mode, and upgrade components in batches.
Recreate: Old pods are deleted, and then new pods are created. This policy is used by default when you upgrade a component in single-batch release mode.

You can configure the component upgrade policy when configuring Advanced Settings.

Configuring a Component Upgrade Policy

Choose Advanced Settings > Upgrade Policy.

Configure the upgrade policy by referring to the following table.

Parameter	Description
Deployment Batch	Number of batches in which component instances are upgraded. The value range is [1, Total number of instances]. Total number of instances refers to the number of running instances of the component. For example, if there are 4 component instances and Deployment Batch is set to 2, these component instances are upgraded in two batches, and each batch involves two component instances. This parameter cannot be set when you perform this operation in Creating and Deploying a Component Based on a Container Using UI Configurations. This parameter can be set when this operation can be performed in other scenarios.
Max. Unavailable Pods	Maximum number of unavailable pods allowed in each rolling upgrade. If the number is equal to the total number of pods, services may be interrupted. (Minimum number of alive pods = Total number of pods – Maximum number of unavailable pods) This parameter can be set when you perform this operation on stateless components in Creating and Deploying a Component Based on a Container Using UI Configurations. The units and value ranges are described as follows: Maximum number of unavailable pods compared with the number of instances. The value ranges from 0 to the number of pods. Maximum percentage of unavailable pods to the total number of pods. The value ranges from 0 to 100. This parameter can be set when you perform this operation on stateless components in other scenarios. The value is determined by the number of instances and Deployment Batch. If there is one instance, the value is 1. If there is more than one instance, the value depends on whether the number of instances can be exactly divided by the value of Deployment Batch. If yes, use the quotient. If no, round down the quotient and then plus 1.
Max. Surge	Maximum number of pods that can be created over the desired number of pods in each rolling upgrade. The units are described as follows: Maximum number of available pods compared with the number of instances. The value ranges from 0 to 2147483647. Maximum percentage of available pods to the total number of pods. The value ranges from 0 to 100. This parameter can be set when you perform this operation on stateless components.
Min. Ready Seconds	Minimum ready time of a new pod without any container crash. A pod is considered available only after the minimum ready time is exceeded. The default value is 0, indicating that a component instance is considered available immediately after it is ready. The value ranges from 0 to 2147483647.
Revision History Limit	Number of old pods to retain to allow rollback. The default value is 10. The value ranges from 0 to 2147483647.
Max. Upgrade Seconds	The time (in seconds) the system waits for before reporting a component upgrade failure. If this parameter is specified, the value must be greater than that of Min. Ready Seconds. The value ranges from 0 to 2147483647.
Scale-in Time Window (s)	The time window for executing commands before a workload stops. The default value is 30s. The value ranges from 0 to 2147483647. You can set a graceful scale-in time window to save important data before a component instance stops. For example, if an application has two instances and only one instance will be kept after the scale-in operation, you can still perform certain operations on the instance to be stopped in the specified time window.