#22: Agent 1 reports to the master that it has 4 CPUs and 4 GB of memory free. The master then invokes the allocation policy module, which tells it that framework 1 should be offered all available resources.
The master sends a resource offer describing what is available on agent 1 to framework 1.
The framework’s scheduler replies to the master with information about two tasks to run on the agent, using <2 CPUs, 1 GB RAM> for the first task, and <1 CPUs, 2 GB RAM> for the second task.
Finally, the master sends the tasks to the agent, which allocates appropriate resources to the framework’s executor, which in turn launches the two tasks (depicted with dotted-line borders in the figure). Because 1 CPU and 1 GB of RAM are still unallocated, the allocation module may now offer them to framework 2.
#26: A Mesos cluster comprises a few masters and many slaves. As work is farmed out to them, Mesos slaves delegate to?executors?for the setup and teardown of individual tasks. It is the executor that manages communication between the slave and the Docker daemon. The Docker daemon manages caching and launch of Docker images, which can be pulled from the global Docker index or a local registry.
When a Docker container is started as a Mesos task, it runs beneath the Docker daemon on a slave server. Although the Docker container does not run as a true child process of the executor, as it would have under the old Docker standalone mode, the executor is able to manage translation of resource limits, signals and Mesos process control messages to appropriate calls of the?docker?tool. Fine-grained resource monitoring, forthcoming in mainline Mesos and part of some service management tools, is hard to do right if the container does not run directly under the executor — so this architecture may be revised in the future.