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 a separate 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 isntances started simultaneously. Acceptable values: 0 to 100. 0 means any number of instances within the allowed range. |
max_deleting |
Maximum number of instances stopped simultaneously. Acceptable values: 0 to 100. 0 means any number of instances within the allowed range. |
max_unavailable |
Maximum number of instances in the RUNNING status by which the group's target size can be reduced.Acceptable values: 0 to 100. |
max_expansion |
Maximum number of instances by which the group's target size can be exceeded1. If the max_unavailable key is not specified or is zero, a non-zero value must be specified for the max_expansion key.Acceptable values: 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 the health checks are passed. The acceptable values range from 0 to 3,600 seconds. |
1 Subsequently, when bringing the number of instances in the group to the target value, instances created under the max_expansion
quota can remain in the group, while those that existed in the group before may be deleted.
Strategies for stopping instances
Instance Groups supports two strategies for stopping instances when updating or automatically scaling a group: automatic (PROACTIVE
) and manual (OPPORTUNISTIC
).
If you use the proactive strategy, Instance Groups will select which instances to stop by itself.
With the opportunistic strategy, Instance Groups does not stop the instances but waits until at least one of the following conditions is met:
- User stops an instance in Compute Cloud.
- Application or user stops the instance internally.
- Instance fails the application health check.
For example, you created an instance group with automatic scaling based on the custom metric of the number of jobs in the queue. Instance Groups creates an instance group that executes 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 the proactive stop, Instance Groups will change the target group size and decrease the actual number of instances in the group to the target amount.
- If you use the opportunistic strategy, Instance Groups will change the target group size but will not stop the instances until they stop by themselves or are stopped 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:
PROACTIVE . |
Minimum instance update actions
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 instance update action 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. For example, if instance restart is selected as the minimum action, the instance may be also deleted if so required by the rules.
You can manage your minimum instance update actions 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 instance update action. Possible values:
LIVE_UPDATE . |