Interface NodeGroupDeploymentStrategy

Returns a safe value for JSON logs.

Preserves protobuf fields that this SDK version does not recognize.

Contains the fully qualified protobuf type name.

Maximum amount of time that the service will spend attempting to gracefully drain a node (evicting its pods) before falling back to pod deletion. A value of 0 means no timeout: the node can be drained for an unlimited time. Important consequence of that is if PodDisruptionBudget doesn't allow evicting a pod, then NodeGroup update with node re-creation will hang on that pod eviction. Note that this is different from kubectl drain --timeout, which gives up and returns an error.

On 2026-08-01, defaults to 0. IMPORTANT: starting from Q3 2026 new default is 10m; for new clusters it will default to 10m, node groups in existing clusters will be gradually migrated during Q3 to the default of 10m as well. To get the actual value for your node group, please see 'strategy' in its status.

The maximum number of additional nodes that can be provisioned above the desired number of nodes during the update process.

This value can be specified either as an absolute number (for example 3) or as a percentage of the desired number of nodes (for example 5%).

When specified as a percentage, the actual number is calculated by rounding up to the nearest whole number. This value cannot be 0 if max_unavailable is also set to 0.

On 2026-08-01, defaults to 1. IMPORTANT: starting from Q3 2026 new default is 0; for new clusters it will default to 0, node groups in existing clusters will be gradually migrated during Q3 to the default of 0 as well. To get the actual value for your node group, please see 'strategy' in its status.

Example: If set to 25%, the node group can scale up by an additional 25% during the update, allowing new nodes to be added before old nodes are removed, which helps minimize workload disruption.

NOTE:

it is user responsibility to ensure that there are enough quota for provision nodes above the desired number. Available quota effectively limits max_surge. In case of not enough quota even for one extra node, update operation will hung because of quota exhausted error. Such error will be visible in Operation.progress_data.

The maximum number of nodes that can be simultaneously unavailable during the update process.

This value can be specified either as an absolute number (for example 3) or as a percentage of the desired number of nodes (for example 5%).

When specified as a percentage, the actual number is calculated by rounding down to the nearest whole number. This value cannot be 0 if max_surge is also set to 0.

On 2026-08-01, defaults to 0. IMPORTANT: starting from Q3 2026 new default is 1; for new clusters it will default to 1, node groups in existing clusters will be gradually migrated during Q3 to the default of 1 as well. To get the actual value for your node group, please see 'strategy' in its status.

Example: If set to 20%, up to 20% of the nodes can be taken offline at once during the update, ensuring that at least 80% of the desired nodes remain operational.