Skip to main content
Who decided on Machine 2? That placement is the result of a short chain of steps Nomad follows for every meaningful change. Understanding that chain makes it much easier to debug why work ended up where it did. It starts the moment Maya submits her job. Nomad compares the job specification with the cluster’s current state. If there’s any difference, Nomad creates an evaluation. An evaluation is simply a question Nomad asks itself: something changed, so what (if anything) needs to happen now? Every meaningful event creates an evaluation — a job submission, a node going offline, a task failure, or a configuration change will trigger one.
A presentation slide showing icons for events—“a job is submitted,” “a machine goes offline,” and “a task dies”—above rows of server/Docker boxes labeled box-1 through box-4. The header reads “An Evaluation Is a Question” with the emphasized message “A decision, not a coin toss.”
That evaluation is delivered to a scheduler process. The scheduler reasons about the current cluster state and produces a plan — a proposal such as “start these tasks on that node” or “stop these tasks.” Plans are forwarded to the servers, but only the cluster leader may accept a plan. The leader’s acceptance is the single source of truth for allocation changes; this prevents conflicting promises for the same scarce resources (for example, the last gigabyte of memory on Machine 2).
A presentation slide showing a decision flow with icons for evaluation, plan, and a leader (scale) and the caption "Only the leader may say yes." Below are four labeled boxes (box-1 to box-4) with server/container icons.
When the leader accepts a plan, Nomad creates an allocation. An allocation is the record that ties a set of tasks to a specific machine. The job is what Maya requested; the allocation is what actually runs on a node.
An evaluation → scheduler plan → leader acceptance → allocation. The leader’s acceptance is what makes a plan real.
Two phases determine which node the scheduler chooses: filter, then score.
  • Filter: eliminate nodes that cannot run the task (hard requirements).
  • Score: rank the remaining eligible nodes and pick the highest-scoring one.
Only nodes that pass all filters are eligible; those survivors are then scored and the highest-scoring node wins.
A presentation slide titled "Filter, Then Score" with magnifying-glass and gauge icons, short error notes ("not in dc1 · out", "not enough memory · out") and the phrase "The job is the promise." Below are four blue container/ship icons above server illustrations labeled box-1 through box-4.
Common filter examples: A common surprise is that Nomad does not try to spread work evenly by default. Its default placement strategy is bin packing: prefer to fill up nodes before using additional ones. Think of it like packing boxes into vans — you fill one van, then the next, rather than putting a single box in each van. Bin packing concentrates workloads so some machines become fully utilized while others remain empty. Those empty machines are purposeful: you can power them down to save cost or reserve them for large jobs that require a lot of capacity in one place.
A presentation slide about bin packing with icons for search, capacity, and scoring and text like "not in dc1 · out", "not enough memory · out", and "what survives is scored." At the bottom are server and container icons labeled box-1 through box-4 and a headline on the right reading "Those numbers earn their keep."
If Maya needs a specific property from the node (for example, only run on Linux or only on machines with NVMe disks), she can add a constraint block to the job. Constraints are hard filters — they remove nodes that don’t meet the condition rather than merely influencing scoring. Example: rescheduling after a node failure Maya deliberately shuts down Machine 2. Nomad detects the node is no longer answering and creates an evaluation. The scheduler produces a replacement plan for the tasks that were on Machine 2, the leader accepts it, and a new allocation is created on Machine 4. The API resumes without manual intervention.
Note that Maya’s job file still declares “run one copy of the API.” What changed is which machine satisfies that promise — Nomad rebuilt the single copy on another node, so Maya doesn’t need to know or care where it runs.
Running a single instance limits availability. If that instance’s node fails, the API is unavailable until Nomad rebuilds it elsewhere. Consider running multiple replicas for higher availability and capacity.
Quick reference: events that trigger an evaluation Further reading and references

Watch Video

Practice Lab