A scheduler is the orchestration component that decides which worker machine should host each task in a job. It turns a pool of machines into a placement system: tasks are assigned to workers while the manager, workers, and command-line interface handle the surrounding control flow. Simple placement can rotate through nodes; more capable placement evaluates available workers before choosing one. section 1.10 section 1.5.3
Figure 1.9 Mental model for Cube. It has a manager, a worker, and a scheduler, and users (i.e., you) will interact with it via a command line.
The scheduler is a distinct part of an orchestration system: it feeds placement decisions into the manager-and-worker workflow. section 1.6
Scheduling has three ordered phases. First, feasibility identifies workers that can run a task. Next, scoring ranks those candidates according to a chosen policy. Finally, picking selects the best-ranked worker. Feasibility may yield no workers or only a subset of the cluster; scoring and picking operate only on that feasible set. section 1.5.3 section 1.6
A scheduler therefore separates placement policy into small responsibilities:
- Select candidate nodes that are feasible for the task. section 2.4
- Score candidate workers from best to worst using the policy’s criteria. section 1.5.3
- Pick the worker with the best score, whether the policy treats the preferred value as highest or lowest. section 1.6
Listing 2.10 The skeleton of the Scheduler component
package scheduler
type Scheduler interface {
SelectCandidateNodes()
Score()
Pick()
}
A Go interface makes the three phases explicit, so multiple placement strategies can satisfy the same scheduler contract. section 2.4 section 2.7
A round-robin scheduler is a useful first implementation: it remembers the worker that received the most recent task and chooses the next worker in its list. Its simplicity also exposes its limits. The next worker might lack memory or disk, and a fixed rotation cannot express whether tasks should be packed onto one worker or spread across workers to reduce resource starvation risk. section 2.4 section 10.0
Resource-aware placement
Suppose a worker has insufficient memory, CPU, or disk for a task. A resource-aware scheduler can account for memory and CPU requirements during placement, but disk can still cause startup failure: container images, logs, and other containers consume local disk after a worker has been selected. section 9.2.3
Placement is not tied to one product’s vocabulary. Borg uses a manager that employs a scheduler to place containerized tasks on workers; Mesos, Kubernetes, and Nomad use related manager, worker, task, job, scheduler, and cluster roles with differing names or structures. A small multi-worker setup makes scheduler behavior visible, while a single worker leaves every job with only one possible destination. section 1.5.7 section 1.8
