You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 5, 2023. It is now read-only.
Services might have a cost associated with starting or stopping replicas. Often this simply is the initialization and shutdown time, but one could also imagine other factors. In these cases keeping the number of replicas stable over a period of time is preferable. For this spate allows to specify cool down times that apply after up and down scales. During this time no autoscaling is performed even if the target is not met. This also guards against artificial low or high measures. For instance after a down scale one metric could be artificially low leading to an up scale. If instead some time passes a more realistic measurement is taken. Cool down times can also be set for other events, i.e. after the service is added or updated. They are specified on a per service basis. If no time is provided a default one applies. The default can be set by the administrator globally.
Design
Each cool down time is associated with an event. By default there is 3m cool down time after a scaled_up event while scaled_down wait for 5m (like the pod autoscaler in Kubernetes). service_added and service_updated have no cool down time. Users can change these with the de.mtneug.spate.loop.cooldown.<event> labels. Administrators can set global defaults with the --default-cool-down-time-<event> CLI options. For service_updateds the cool down time of the new service definition is used.
Example
# Setting the global default
$ spate \
--default-cool-down-time-scaled_up=30s \
--default-cool-down-time-scaled_down=20m \
--default-cool-down-time-service_added=2m \
--default-cool-down-time-service_updated=1m
# Overwriting the default
$ docker service create \
--name service \
--label de.mtneug.spate.metrics.cpu.type=cpu \
--label de.mtneug.spate.loop.cooldown.scaled_up=30s \
--label de.mtneug.spate.loop.cooldown.scaled_down=20m \
--label de.mtneug.spate.loop.cooldown.service_added=2m \
--label de.mtneug.spate.loop.cooldown.service_updated=1m \
...
my/service
The text was updated successfully, but these errors were encountered:
mtneug
changed the title
The user can declare cool down time after up/down scales
The user can declare cool down times after various events
Dec 1, 2016
Description
Services might have a cost associated with starting or stopping replicas. Often this simply is the initialization and shutdown time, but one could also imagine other factors. In these cases keeping the number of replicas stable over a period of time is preferable. For this
spate
allows to specify cool down times that apply after up and down scales. During this time no autoscaling is performed even if the target is not met. This also guards against artificial low or high measures. For instance after a down scale one metric could be artificially low leading to an up scale. If instead some time passes a more realistic measurement is taken. Cool down times can also be set for other events, i.e. after the service is added or updated. They are specified on a per service basis. If no time is provided a default one applies. The default can be set by the administrator globally.Design
Each cool down time is associated with an event. By default there is
3m
cool down time after ascaled_up
event whilescaled_down
wait for5m
(like the pod autoscaler in Kubernetes).service_added
andservice_updated
have no cool down time. Users can change these with thede.mtneug.spate.loop.cooldown.<event>
labels. Administrators can set global defaults with the--default-cool-down-time-<event>
CLI options. Forservice_updated
s the cool down time of the new service definition is used.Example
The text was updated successfully, but these errors were encountered: