Deployment policy
When creating an instance group, you can choose how the instances will be deployed in the group.
The deployment policy is a set of restrictions defined in the deploy_policy
key in the YAML file. Each restriction is set in its own key as a key-value
pair.
Here is how a YAML file entry may look like:
...
deploy_policy:
max_creating: 10
max_deleting: 10
max_unavailable: 10
max_expansion: 0
startup_duration: 30s
...
Where:
Key | Value |
---|---|
max_creating |
Maximum number of instances being started at the same time. Valid values range from 0 to 100. 0 means any number of instances within the allowed range. |
max_deleting |
Maximum number of instances being stopped at the same time. Valid values range from 0 to 100. 0 means any number of instances within the allowed range. |
max_unavailable |
Maximum number of instances in the RUNNING status that can be removed to reduce the target size of the group.Valid values range from 0 to 100. |
max_expansion |
Maximum number of instances that can be additionally allocated to expand the target size of the group. If the max_unavailable key is not specified or is zero, the max_expansion key value must not be zero.Valid values range from 0 to 100. |
startup_duration |
Startup duration of an instance in the group. The instance starts receiving traffic only after the startup time expires and all health checks are passed. Valid values range from 0 to 100. |
Strategies for stopping instances
Instance Groups supports two strategies for stopping instances when updating or automatically scaling a group: PROACTIVE
and OPPORTUNISTIC
.
If you use the proactive strategy, Instance Groups will select which instances to stop on its own.
With the opportunistic strategy, Instance Groups, rather than stopping the instances, will wait until at least one of the following conditions are met:
- User stops an instance in Compute Cloud.
- Application or user stops the instance internally.
- Instance fails the application health check.
For example, let's assume you created an instance group with automatic scaling based on the custom metric of the number of jobs in the queue. Instance Groups will create an instance group to run the jobs from the queue. As soon as there are no more jobs, Instance Groups must reduce the group size from the actual size to the target one according to the scaling policy.
- If you selected proactive stop, Instance Groups will change the target group size and decrease the actual number of instances in the group to the target amount.
- Under the opportunistic strategy, Instance Groups will change the target group size, but will not stop the instances until they are stopped by themselves or by the user.
Here is how a YAML file entry may look like:
...
deploy_policy:
strategy: OPPORTUNISTIC
...
Where:
Key | Value |
---|---|
strategy |
Strategy for stopping instances in a group. Possible values include:
PROACTIVE . |
Minimum actions to perform for an instance's update
By default, when updating an instance, Instance Groups decides whether to restart or recreate them based on the rules. However, you can also set the minimum action to perform for updating an instance yourself. It will be executed even if the rules do not require that. This may be needed for cleaning up RAM or disks at an instance's update or redeploying the instance.
Please note that the update rules take priority over the minimum actions you set. For example, if you select an instance's restart as the minimum action, the instance may also be deleted if this is required by the rules.
You can manage minimum actions to perform for an instance's update using the CLI and API.
Here is how a YAML file entry may look like:
...
deploy_policy:
minimal_action: RESTART
...
Where:
Key | Value |
---|---|
minimal_action |
Minimum action to perform for an instance's update. The possible values include:
LIVE_UPDATE . |