liveBook · Manning

Cube

As explained in Build and Orchestrator in Go (From Scratch)

The book's orchestration system that schedules and runs task instances on worker nodes.

Cube is a small orchestration system for running task instances across worker nodes. It reduces an orchestrator to three main responsibilities: workers execute tasks, a manager accepts tasks and coordinates the system, and a scheduler selects a worker. Users interact with the manager rather than deciding which worker should run each task. section 1.6 section 7.0

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.
01-09

Use the mental model to trace the path from command-line user to manager, scheduler, and worker. section 1.6

Scheduling proceeds in three phases. Feasibility filters workers that cannot accept a task, scoring ranks the feasible workers, and picking chooses the best score. Cube’s initial manager uses a simpler round-robin policy, while the scheduler is represented by an interface so alternative policies can be added. section 1.6 section 2.7 section 7.0

Cube makes orchestration state explicit:

  • Tasks move through Pending, Scheduled, Running, Completed, and Failed states. section 2.7
  • The manager keeps task and event stores plus mappings between tasks and workers, making placement and task location trackable. section 7.3.5
  • The manager can respond to a failed task with a restart request or placement on another worker with capacity. section 9.3.3

A manager takes over placement

Instead of asking a user to inspect workers and choose one manually, a user submits a task to the single manager. The manager applies its scheduling policy, sends the task to a worker, and tracks where it runs. This central view also gives it options when a worker is overloaded, unavailable, or hosting a failed task. section 7.0 section 9.3.3

Cube is organized around Manager, Node, Scheduler, Task, and Worker components. Its command-line interface can start workers and the manager independently, start and stop tasks, query task status, and inspect node state. The implementation is intentionally simpler and less resilient than production orchestrators, while retaining their core component roles. section 1.6 section 2.7 section 12.0 section 13.0

How Build and Orchestrator in Go (From Scratch) covers it

How deep it goes
Builds manager, worker, scheduler, task state, storage, and CLI components, while deliberately simplifying production resilience.
Examples
Uses round-robin placement, task-state transitions, manager maps, and failed-container recovery scenarios.
What it assumes
Introduces orchestration components through skeletons while using Go interfaces to express interchangeable scheduler behavior.
What you can do after
Build it from scratch as a simplified orchestrator with independently runnable manager and worker processes.
How it connects
Connects manager, worker, scheduler, task state, Docker API, HTTP API, storage, and command-line interface.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Build and Orchestrator in Go (From Scratch). The section links point to the parts of the book it draws on.