目前集群管理工具简单罗列，待日后一一使用再来详写。
写的比较清楚的：容器时代,集群调度谁家强? swarm参考：深入浅出Swarm，Docker集群的管理工具 marathon参考：使用Mesos和Marathon管理Docker集群 marathon搭建参考：Marathon主要功能介绍(-) Swarm、Fleet、Kubernetes、Mesos - 编排工具对比分析
Machine 在没有Machine时，安装docker需要根据不同的OS使用不同的安装方法，配置文件也在不同的位置，流程复杂而且不简单方便。Machine就是解决的是操作系统异构安装Docker困难的问题。 有了Machine，所有的系统都是一样的安装方式，一个命令直接安装Docker引擎，这样就有了docker环境。 Swarm Machine帮我们快速构建docker环境，但是那是单机的。Swarm管理docker集群，支持用户创建docker engine主机资源池，并提供docker集群环境和调度策略等。 有了Swarm，能够对集群调度管理，就有了docker 容器运行的资源池环境。 Compose 有了集群环境，下面就是部署应用，有时候就需要多容器组装应用，这个时候我们需要docker run image1、docker run image2 …，进行大量重复操作和配置。 Compose就是简化部署应用流程，只需要把命令参数固化到docker-compose.yml中，维护所有应用程序容器的逻辑定义以及它们之间的连接关系。
docker swarm
一套Docker Swarm架构由一个Swarm manager（运行Swarm daemon）和若干Swarm节点组成。用户只需跟Swarm manager通信，然后Swarm manager根据discovery service的信息选择一个Swarm节点来运行容器
swarm官方文档
1.12版Docker Engine，最大的新特性是Docker Swarm已经被整合到了Docker Engine里面而不再是一个单独的工具了，这样就可以更容易的把多个Docker主机组合成一整个规模更大可靠性更高的逻辑单元.
具体的swarm架构：
>通过所有Docker Node的状态以及具体信息，来筛选（filter）决策到底哪些Docker Node满足要求，并通过一定的策略（strategy）将请求转发至具体的一个Docker Node.
当Swarm Server被初始化并完成监听之后，用户即可以通过Docker Client向Swarm发送Docker集群的管理请求。
请求入口为Swarm Server，处理引擎为Scheduler，节点信息依靠Disocovery.
filter
Filters tell Docker Swarm scheduler which nodes to use when creating and running a container。 docker.com对于filter讲解
策略
策略有三个： - spread: 默认策略，尽量均匀分布，找容器数少的结点调度（默认策略） - binpack: 和spread相反，尽量把一个结点占满再用其他结点（当使用binpack策略时，必须指定资源的占用大小） - random: 随机 修改Docker 1.12的代码把replica容灾的策略加到Swarm调度策略 新的Swarm调度算法和老Swarm差不多，不过不再提供策略选择，只提供了spread策略。
fleet
CoreOS上的Fleet，第二部分 fleet 是通过systemd来控制你的集群的，控制的任务被称之为unit（单元）,控制的命令是fleetctl。 Fleet是CoreOS的一个调度和集群管理组件。它从集群中etcd（CoreOS所使用的一个分布式key-value存储，用来创建分布式init系统）中读取每一个宿主机上的连接信息，然后提供systemd类似的服务管理。
fleet逻辑框架：
每个机器运行一个引擎和一个代理，任何时候在集群中只激活一个引擎，但是所有代理会一直运行，Systemd单元文件被提交给引擎，然后在 least-loaded机器上调度任务，单元文件会简单运行一个容器，代理会启动单元和报告状态，Etcd用来激活机器间的通讯以及存储集群和单元的状态。
单元的调度可以是全局的：一个实例将在所有机器上运行，或者作为一个单独的单元运行在一台机器上。全局调度对于如日志和监控容器任务非常实用。
主要
单元配置文件定义了你要在集群中跑的服务。可以想成它就是fleet管理应用的方式 通过fleet运行一个服务，需要几个必要的步骤： 1.上传单元配置文件 2.fleet读取单元配置文件 3.fleet安排load单元配置文件去机器上run，涉及到scheduling: fleet不是一个具有资源意识的调度器,调度时fleet并不将诸如CPU和内存等可用的系统资源纳入考虑范围,fleet会判断哪个节点目前运行的单元文件最少，然后将下一个单元文件调向该节点. 4.start在目标主机上启动该单元服务。
marathon
是Mesosphere的一个调度和服务管理组件。它配合mesos来控制长时间运行的服务，并为进程和容器管理提供Web界面。
mesos
Apache mesos是一个抽象和管理集群中所有宿主资源的工具：能够在同样的集群机器上运行多种分布式系统类型，更加动态有效率低共享资源。提供失败侦测，任务发布，任务跟踪，任务监控，低层次资源管理和细粒度的资源共享，可以扩展伸缩到数千个节点。Mesos已经被Twitter用来管理它们的数据中心。
-
Mesos架构图如下：
它被称为是分布式系统的内核.
执行器是一个docker容器：
-
Mesos主从服务器调度资源的顺序图如下：
首先由Mesos主服务器查询可用资源给调度器，第二步调度器向主服务器发出加载任务，主服务器再传达给从服务器，从服务器向执行器命令加载任务执行，执行器执行任务以后，将状态反馈上报给从服务器，最终告知调度器 。 -
mesos两级调度架构
Mesos实现了两级调度架构，它可以管理多种类型的应用程序。第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。上图中只展示了Hadoop和MPI两种类型，其它类型的应用程序也有相应的Framework。
Mesos Master协调全部的Slave，并确定每个节点的可用资源， 聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行
Marathon
因为Marathon会将运行时的一些状态state存储在Zookeeper中，同时在Marathon高可用模式下，Marathon Leader的选举也依赖于Zookeeper,所以首先我们必须先运行一个Zookeeper集群来为多个Marathon服务之间共享状态和Leader的选举 ## Kubernetes
compose
定义配置文件来提供容器组管理功能
fleet: a native scheduler to CoreOS (not resource aware) Swarm的优点是支持过滤器和描述如何优化一个容器在集群的调度方式的策略。