本文转载自http://dockone.io/article/1138 并有所增减
什么是调度（scheduling）？
调度
一个集群调度工具有多个目的：使得集群的资源被高效利用，支持用户提供的配置约束（placement constraint），能够迅速调度应用以此保证它们不会处于待定状态（pending state），有一定程度的“公平”（fairness），具有一定的鲁棒性和可用性。为了达到这些目的，在一篇关于Omega（一个由Google开发的，针对大型计算集群的可扩展调度框架）的白皮书中，提到了三个主要的调度架构[48]：
一体式调度（Monolithic scheduling）
一体式调度框架由单一的调度代理（scheduling agent）组成，它负责处理所有的请求，这种框架通常应用于高性能计算。一体式框架通常实现了一个单一的算法来处理所有的作业（job），因此根据作业的类型来运行不同的调度逻辑是困难的。
Apache Hadoop YARN[55]是一个非常流行的架构，尽管它将许多调度功能都分发到每一个应用模块中，但它依然是一体式的调度架构，因为，实际上，所有的资源请求都会被发送到一个单一的全局调度模块。
两级调度（Two-level scheduling）
两级调度框架会利用一个中央协调器（central coordinator）来动态地决定各个调度模块可以调用多少资源。这项技术被应用于Mesos[50]和Hadoop-on-Demand（现在被YARN取代了）。
在这类架构里，分配器会将给定的资源一次性分配个一个框架，因此避免了资源使用的冲突，并且通过控制资源分配的顺序和大小来实现一种相对的资源公平分配。然而，一个资源每次只能被一个框架使用，因此并发控制被称之为悲观的（pessimistic），这种控制策略是不易于出错的（less error-prone），但是相对于将一个资源同时分配个多个框架的乐观并发式控制来说，速度是更慢的。
共享状态调度（Shared-state scheduling）
Omega 赋予了每一个调度器（scheduler）对整个集群的全部访问权限，也就是说调度器们可以自由地竞争。因为所有的资源分配都发生在各个调度器中，所以也就没有了中央资源分配器。也就是说，没有了中央策略引擎，每一个调度器能够自己做决定。
通过支持独立的调度器实现和公布整个资源分配的状况，Omega不仅支持扩展多个调度器，还能够支持它们自己的调度策略[54]
什么是容器（container）？
Docker是一个主流容器管理工具，它是第一个基于Linux容器（LXC）的[2]，但是现在被runC[46]所取代了（runC是是一个由Open Containers Initiative开发的CLI工具，它能够创建和运行容器[36]）。Docker容器支持分层的文件系统，因此它能够和宿主机共享系统内核。这个特性意味着即便一个Docker镜像基于一个1GB的操作系统，在同一个主机上运行10个容器实例并不需要消耗10GB的空间，相比之下，每一台虚拟机都需要一个完整的1GB操作系统。
Virtual machines architecture compared to containers, © Docker Inc. [23]
Docker的镜像可以理解为一个操作系统的快照。如果你想要创建一个新的镜像，你需要启动一个基础镜像，然后做一些修改，最后提交修改，形成新的镜像。这些镜像能够发布在私有或者公有的库上[10]供其他开发者使用，开发者只需要将镜像pull下来即可。
使用镜像可以非常方便的创建操作系统的快照，并且使用它们来创建新的容器，这些功能非常的轻量和易用，这些都是Docer CLI和商业模式的核心。[12]
容器包含了所有运行所需要的东西（代码，运行时，系统工具，库），因此Docker给予开发者一个轻量的，稳定的环境来快速地进行创建和运行作业。
容器调度简介（Description of container schedulers）
容器调度工具的主要任务就是负责在最合适的主机上启动容器，并且将它们关联起来。它必须能够通过自动的故障转移（fail-overs）来处理错误，并且当一个实例不足以处理/计算数据时，它能够扩展容器来解决问题。
这篇文章比较了三个主流容器调度框架：Docker Swarm [13], Apache Mesos (running the Marathon framework) [50] and Google Kubernetes [31]。
Docker Swarm
Apache Mesos & Mesosphere Marathon
Kubernetes
比较
| Kubernetes | Swarm | Note | |
|---|---|---|---|
| Installation and setup | No installation required for managed offerings from cloud providers. | Install it with Docker. | |
| Scalability | Built-in with horizontal autoscaling. | Autoscaling groups. | Swarm is known to be more scalable than Kubernetes. Containers can be deployed faster both when it comes to large clusters and high cluster fill stages. Only a single update command is enough to deploy new replicas.On the other hand, Auto-scaling is as smooth with Swarm as it is with Kubernetes, |
| Load balancing | Discovery of services through a single DNS name. Access to container applications through IP address or HTTP route. | Internal load balancing. A common network is joined by all containers that are in the same cluster. This allows connection of any node to any container. | |
| High availability | Self-healing and intelligent scheduling. | Use Swarm Managers for availability controls | |
| Building and Running Containers | Kubernetes embraces uniqueness by having its own API, client, and YAML definitions. | The same Docker CLI is used and new containers can be spinned with a single command | |
| Logging and Monitoring | Inbuilt tools have been included in Kubernetes for the purpose of Logging and Monitoring. | Swarm lacks the capability of inbuilt tools to handle Logging and Monitoring. Use external tools such like ELK | |
| Networking | The networking model is a flat network, allowing all pods to interact with one another. The flat network is implemented typically as an overlay. The model needs two CIDRs: one for the services and the other from which pods acquire an IP address. | The Node joining a swarm cluster generates an overlay network for services that span every host in the docker swarm and a host-only docker bridge network for containers. | |
参考
https://hackernoon.com/kubernetes-vs-docker-swarm-a-comprehensive-comparison-73058543771e
https://cloud.tencent.com/developer/article/1361203
http://dockone.io/article/1138
http://www.dockone.io/article/1145