A manager node is the control component of a container orchestrator. Users submit work to it rather than choosing a worker themselves; it schedules tasks, records desired and observed state, and coordinates the cluster without directly running containers. section 1.5.4 section 7.6
Figure 7.1 The manager is responsible for administrative tasks, similar to the function of a restaurant host seating customers. It will use the worker’s /tasks and /stats API endpoints to perform its administrative duties.
The manager forms the control side of the system: users communicate with it, while it queries and directs one or more workers. section 7.1 section 8.1
Treat the manager as the cluster-wide view. A worker knows the tasks assigned to its own machine, but the manager tracks workers, task locations, task states, and available capacity across the cluster. That wider view lets it select an appropriate worker and later react to failures by restarting a task or placing it elsewhere. section 1.9.3 section 9.3.3
A practical manager separates administrative decisions from execution:
- Accept start and stop requests, representing requested task state as task events. section 1.5.4 section 7.6
- Choose a worker for each pending task, initially with a simple round-robin policy or later with resource-aware scheduling. section 7.0 section 1.6
- Send assigned work to workers, which run the containers and expose task and machine information. section 1.5.5 section 7.6
- Poll workers for task updates and synchronize the manager’s task records with actual task state. section 7.3.3 section 7.6
A minimal implementation keeps a FIFO pending queue, task and event stores, a worker list, and mappings between workers and task IDs. Separate selection, dispatch, and update operations make the control flow explicit: select a worker, send the task, then periodically refresh its status. section 2.3 section 7.3 section 7.3.5
Polling task state after dispatch
After sending a task, a successful HTTP response only confirms that the worker accepted it; it does not prove the container started. For every worker, request GET /tasks, decode the returned tasks, and update stored state, timestamps, and container IDs. This reveals failures such as a missing image, full disk, or an application that cannot start. section 7.3.3
Manager availability has a distinct failure profile. If a manager fails, running tasks can continue because workers operate independently, but users cannot submit new tasks or stop existing ones until management is restored. Multiple managers improve resilience but require synchronized cluster state, leadership decisions, and consensus-related design. section 9.2.7 section 9.3.5
The manager is a control-plane role, not necessarily a particular product label. Other orchestrators use names such as BorgMaster, control plane, master, or server, but each centralizes user-facing administration and task placement while workers perform execution. section 1.5.7 section 7.1
