A new platform for documentation and tutorials is launching soon.
We are migrating Nomad documentation into HashiCorp Developer, our new developer experience.
»Node Selector Strategy
The node selector strategy is a mechanism the Nomad Autoscaler uses to identify nodes for termination when performing horizontal cluster scale-in actions. It is exposed as a target configuration option so that operators can modify its behaviour based on requirements.
least_busy Node Selector Strategy
least_busy strategy is the default node selector strategy used if the
node_selector_strategy configuration option is omitted. When used, the Nomad
Autoscaler will sort nodes based on their overall CPU and memory allocation;
picking those with the lowest values. In the event a number of nodes have the
same allocated percentage value, the selection will be random according to Golang's
least_busy strategy suits workloads that can tolerate migrations but
allows you to minimise such events.
empty Node Selector Strategy
empty strategy will only consider nodes eligible for termination if they
have zero non-terminal allocations. The terminal status of an allocation is
determined using these Nomad SDK allocation functions.
The strategy will skip any node that does not meet this requirement. This can
result in scaling actions terminating a smaller number of nodes than desired. In
the event no nodes are found to be empty, the Nomad Autoscaler will decline to
perform the scaling action.
empty strategy is ideal for batch workloads, ensuring allocations are not
interrupted by scaling.
empty_ignore_system Node Selector Strategy
empty_ignore_system strategy is similar to
empty, but it will not
consider allocations from system jobs. A node with only
terminal allocations and allocations from system jobs is considered empty under
newest_create_index Node Selector Strategy
newest_create_index strategy is the simplest strategy and uses the order
in which nodes are returned by the Nomad SDK. The
strategy is ideal for workloads and environments which can handle migrations
due to scaling. It is also the least computationally intensive selector strategy.