Choosing a Scheduler¶

The Scheduler creates, starts, stops, and destroys each Container of your app. For example, a command such as deis scale web=3 tells the scheduler to run three containers from the Docker image for your app.

Deis defaults to using the Fleet Scheduler. Tech previews of schedulers based on Kubernetes, Mesos with Marathon, and Swarm are available for testing.

Note

If you are using a scheduler other than fleet, app containers will not be rescheduled if deis-registry is unavailable. For more information, see deis-registry issue 3619.

Settings set by scheduler¶

The following etcd keys are set by the scheduler module of the controller component.

Some keys will exist only if a particular schedulerModule backend is enabled.

setting	description
/deis/scheduler/swarm/host	the swarm manager’s host IP address
/deis/scheduler/swarm/node	used to identify other nodes in the cluster
/deis/scheduler/mesos/marathon	used to identify Marathon framework’s host IP address
/deis/scheduler/k8s/master	used to identify host IP address of kubernetes ApiService

Settings used by scheduler¶

The following etcd keys are used by the scheduler module of the controller component.

setting	description
/deis/controller/schedulerModule	scheduler backend, either “fleet” or “swarm” or “mesos_marathon” or “k8s” (default: “fleet”)

Fleet Scheduler¶

fleet is a scheduling backend included with CoreOS:

fleet ties together systemd and etcd into a distributed init system. Think of it as an extension of systemd that operates at the cluster level instead of the machine level. This project is very low level and is designed as a foundation for higher order orchestration.

fleetd is already running on the machines provisioned for Deis: no additional configuration is needed. Commands such as deis ps:restart web.1 or deis scale cmd=10 will use fleet by default to manage app containers.

To use the Fleet Scheduler backend explicitly, set the controller’s schedulerModule to “fleet”:

$ deisctl config controller set schedulerModule=fleet

Kubernetes Scheduler¶

Important

The Kubernetes Scheduler is a technology preview and is not recommended for production use. Since it requires overlay networking, Kubernetes can only be enabled on a new cluster.

Kubernetes is an orchestration system for Docker containers:

Kubernetes (k8s) provides APIs to manage, deploy and scale Docker containers. Kubernetes deploys containers as pods, providing a unique entity across a cluster, but allowing containers within the pod to share a namespace.

Kubernetes requires the flannel overlay network so each pod receives a unique IP address within the cluster. Existing Deis clusters cannot simply turn on overlay networking. Instead, provision a new cluster to enable flannel.

To test the Kubernetes Scheduler, first install and start the Kubernetes components:

$deisctl install k8s && deisctl start k8s

Then set the controller’s schedulerModule to “k8s”:

$ deisctl config controller set schedulerModule=k8s

The Kubernetes scheduler is now active. Commands such as deis destroy or deis scale web=9 will use the Kubernetes ApiServer to manage app pods.

Deis creates a replication controller to manage pods and a service which proxies traffic to the pods for your app. Unlike other Deis schedulers, new app releases on Kubernetes do a rolling deploy: pods with the new release replace old pods one at a time, until all are replaced (or until an error forces a rollback to the previous release).

Note

Known Issues

The flannel overlay network is not backward-compatible with earlier Deis clusters, since it changes Docker networking and requires new units from Deis’ user-data file.
The Kubernetes ApiServer is not HA. If the ApiServer is rescheduled, it will reschedule all Kubernetes units.
Kubernetes implements resource-based scheduling. Specifying limits will create a reservation of that resource on the node.

Mesos with Marathon framework¶

Important

The Mesos with Marathon framework Scheduler is a technology preview and is not recommended for production use.

Mesos is a distributed system kernel:

Mesos provides APIs for resource management and scheduling. A framework interacts with Mesos master and schedules and task. A Zookeeper cluster elects Mesos master node. Mesos slaves are installed on each node and they communicate to master with available resources.

Marathon is a Mesos framework for long running applications:

Marathon provides a Paas like feel for long running applications and features like high-availablilty, host constraints, service discovery, load balancing and REST API to control your Apps.

Deis uses the Marathon framework to schedule containers. Since Marathon is a framework for long-running jobs, Deis uses the Fleet Scheduler to run batch processing jobs. deisctl installs a standalone Mesos cluster. To install an HA Mesos cluster, follow the directions at aledbf-mesos, and set the etcd key /deis/scheduler/mesos/marathon to any Marathon node IP address. If a request is received by a regular Marathon node, it is proxied to the master Marathon node.

To test the Marathon Scheduler backend, first install and start the mesos components:

$ deisctl install mesos && deisctl start mesos

Then set the controller’s schedulerModule to “mesos_marathon”:

$ deisctl config controller set schedulerModule=mesos_marathon

The Marathon framework is now active. Commands such as deis destroy or deis scale web=9 will use Marathon to manage app containers.

Deis starts Marathon on port 8180. You can manage apps through the Marathon UI, which is accessible at http://<Marathon-node-IP>:8180

Note

Known Issues

deisctl installs a standalone mesos cluster as fleet doesn’t support runtime change to metadata. You can specify this in cloud-init during the deployment of the node. keep watching dynamic metadata fleet PR 1077.
If you want to access Marathon UI, you’ll have to expose port 8180 in the security group settings. This is blocked off by default for security purposes.
Deis does not yet use Marathon’s docker container API to create containers.
CPU shares are integers representing the number of CPUs. Memory limits should be specified in MB.

Swarm Scheduler¶

Important

The Swarm Scheduler is a technology preview and is not recommended for production use.

swarm is a scheduling backend for Docker:

Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host.

Swarm serves the standard Docker API, so any tool which already communicates with a Docker daemon can use Swarm to transparently scale to multiple hosts...

Deis includes an enhanced version of swarm v0.2.0 with node failover and optimized locking on container creation. The Swarm Scheduler uses a soft affinity filter to spread app containers out among available machines.

Swarm requires the Docker Remote API to be available at TCP port 2375. If you are upgrading an earlier installation of Deis, please refer to the CoreOS documentation to enable the remote API.

Note

Known Issues

It is not yet possible to change the default affinity filter.

To test the Swarm Scheduler backend, first install and start the swarm components:

$ deisctl install swarm && deisctl start swarm

Then set the controller’s schedulerModule to “swarm”:

$ deisctl config controller set schedulerModule=swarm

The Swarm Scheduler is now active. Commands such as deis destroy or deis scale web=9 will use swarm to manage app containers.

To monitor Swarm Scheduler operations, watch the logs of the swarm-manager component, or spy on Docker events directly on the swarm-manager machine: