See the getting started page for more information about downloading, building, and deploying Mesos.
See our community page for more details.
Containerizers are Mesos components responsible for launching containers. They own the containers launched for the tasks/executors, and are responsible for their isolation, resource management, and events (e.g., statistics).
--containerizers). If multiple containerizers (e.g., docker,
mesos) are specified using the --containerizers flag, then the
composing containerizer will be used to create a containerizer.TaskInfo, Mesos agent will use
the default executor for the task (depending on the Containerizer
the agent is using, it could be mesos-executor or
mesos-docker-executor). TODO: Update this after MESOS-1718 is
completed. After this change, master will be responsible for
generating executor information.Mesos currently supports the following containerizers:
Composing containerizer will compose the specified containerizers
(using agent flag --containerizers) and act like a single
containerizer. This is an implementation of the composite design
pattern.
Docker containerizer manages containers using the docker engine provided in the docker package.
ContainerInfo::type is set to DOCKER.A) Mesos agent runs in a docker container
--docker_mesos_image. In this case, the value of flag
--docker_mesos_image is assumed to be the docker image used to
launch the Mesos agent.mesos-docker-executor is launched in a docker container to
execute the command via Docker CLI.B) Mesos agent does not run in a docker container
mesos-docker-executor.
mesos-docker-executor then spawns a shell to execute the command via Docker
CLI.Mesos containerizer is the native Mesos containerizer. Mesos
Containerizer will handle any executor/task that does not specify
ContainerInfo::DockerInfo.
Launcher is responsible for forking/destroying containers.
clone system call.Starting from Mesos 1.1.0, nested container is supported. The Linux Launcher is responsible to fork the subprocess for the nested container with appropriate Linux namespaces being cloned. The following is the table for Linux namespaces that are supported for top level and nested containers.
| Linux Namespaces | Top Level Container | Nested Container |
|---|---|---|
| Mount | Not shared | Not shared |
| PID | Configurable | Configurable |
| Network & UTS | Configurable | Shared w/ parent |
| IPC | Not shared -> configurable (TBD) | Not shared -> configurable (TBD) |
| Cgroup | Shared w/ agent -> Not shared (TBD) | Shared w/ parent -> Not shared (TBD) |
| User (not supported) | Shared w/ agent | Shared w/ parent |
*Note: For the top level container, shared means that the container
shares the namespace from the agent. For the nested container, shared
means that the nested container shares the namespace from its parent
container.
Isolators are responsible for creating an environment for the containers where resources like cpu, network, storage and memory can be isolated from other containers.
© 2012-2022 The Apache Software Foundation. Apache Mesos, the Apache feather logo, and the Apache Mesos project logo are trademarks of The Apache Software Foundation.