Comparison
Cluster autoscalingvsHorizontal autoscaling
Cluster autoscaling
a workload could not be placed, so a new machine was bought, booted and joined the cluster — three minutes after you needed it.
Adding and removing nodes in response to unschedulable workloads and to nodes that could be emptied. It is the layer that turns pod autoscaling into an actual change in what you are paying, and it operates on a much slower clock because it involves provisioning machines. Scale-down is the harder half: one workload with no other home, or a restrictive disruption budget, will keep an almost-empty expensive node alive indefinitely.
Full entry →Horizontal autoscaling
traffic doubled and the replica count went from four to nine on its own, a minute or two after it needed to.
Adding and removing copies of a workload automatically based on a metric — CPU, memory, queue depth, request rate. It is the standard elasticity mechanism and it works well for stateless request handlers whose load metric is honest. Its two constant problems are lag, because the metric arrives after the traffic did, and flapping, which is why cooldown windows exist and why a scale signal tied to a lagging indicator makes things worse.
Full entry →