Configuring a Component Upgrade Policy

Configuring a Component Upgrade Policy

1. Choose Advanced Settings > Upgrade Policy.
2. 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 a Component Based on a Container Using Manual Configurations or Upgrading a Component in Single-batch Release Mode. 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 components whose Workload Type is Stateless in Creating a Component Based on a Container Using Manual 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 an upgrade failure for components whose Workload Type is Stateless. 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.
   Upgrade Method	This parameter can be set when Upgrading a Component in Rolling Release Mode for components whose Workload Type is Stateful. Rolling upgrade Gradually replaces old pods with new ones. During the upgrade, service traffic is evenly distributed to both old and new pods to ensure service continuity. Automatic replacement upgrade You can set First Batch of Instances to Be Upgraded to select the first batch of pods to be upgraded based on the Tag Key, Tag Value, and Operator. In: filters pods with the specified tag key in the tag value list. Multiple tag values are separated by semicolons (;). The tag value is a string. NotIn: filters pods with the specified tag key not in the tag value list. Multiple tag values are separated by semicolons (;). The tag value is a string. Exists: filters pods with the specified tag key. You do not need to enter the tag value. DoesNotExist: filters pods without the specified tag key. You do not need to enter the tag value. The system will automatically use the latest configuration to start new pods to replace the first batch of pods.