57f8ebfa26
* Adding check-legacy-links-format workflow * Adding test-link-rewrites workflow * chore: updates link checker workflow hash * Migrating links to new format Co-authored-by: Kendall Strautman <kendallstrautman@gmail.com>
53 lines
2.5 KiB
Plaintext
53 lines
2.5 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Autoscaling Concepts
|
|
description: >
|
|
This section covers concepts of the Nomad Autoscaler and explains
|
|
technical details of its operation.
|
|
---
|
|
|
|
# Nomad Autoscaler Concepts
|
|
|
|
This section covers concepts of the Nomad Autoscaler and explains the technical
|
|
details of how it functions, its architecture, and sub-systems.
|
|
|
|
The Nomad Autoscaler is modeled around the concept of a closed-loop control
|
|
system. These types of systems are often at the core of self-regulating
|
|
mechanisms because they are able to adjust some value based on the current
|
|
state of the system and some user provided configuration. An example of a
|
|
closed-loop control system is a thermostat, where you set the desired
|
|
temperature and the appliance will regulate the output of cold and hot air to
|
|
make sure the room stays at the value set.
|
|
|
|
In closed-loop systems there are a few key components:
|
|
|
|
* **Setpoint** is the desired output as defined by the user.
|
|
* **Comparator** computes the difference between the setpoint and current
|
|
state of the system.
|
|
* **Controller** connects all the components together and defines what
|
|
needs to be done to bring the system closer to the desired state.
|
|
* **Actuator** applies the changes defined by the controller.
|
|
* **System** is the entity being controlled.
|
|
* **Output** is the current value of the system.
|
|
* **Sensor** reads the system output and translates it to a value that can be
|
|
used by the controller.
|
|
|
|
[![Closed-loop controller](/img/autoscaling/control-loop.png)](/img/autoscaling/control-loop.png)
|
|
|
|
The Nomad Autoscaler follows this same base architecture and offloads some of
|
|
the components to [different types of plugins](/nomad/tools/autoscaling/concepts/plugins).
|
|
|
|
* The autoscaling **policy** is how users define their desired outcome and
|
|
control the Nomad Autoscaler.
|
|
* **Target** is what users want to scale. It can be a job group, where the
|
|
number of allocations is scaled, or a set of Nomad clients, where the number
|
|
of nodes is what changes.
|
|
* **Strategy plugins** receive the current status of the scaling target (such
|
|
as the number of allocations of a group) and metrics of the system to compute
|
|
what actions need to be taken.
|
|
* **Target plugins** communicate with targets to both read its status and to
|
|
apply changes defined by the Autoscaler.
|
|
* **APM plugins** read application performance metrics from external sources.
|
|
|
|
[![Nomad Autoscaler architecture](/img/autoscaling/autoscaler-arch.png)](/img/autoscaling/autoscaler-arch.png)
|