容器集群管理平台的比较

容器化和微服务是当前最热话题，不久之前，笔者（据说因为现在都不用笔了，“笔者”的称谓已经不合适了，因为输入用键盘，叫“键人”更为合适）参加QCon上海一个微服务监控的Session，场面爆棚，我不得不在拥挤的过道听完了整个session。随着要管理的容器越来越多，容器的集群管理平台成为了刚需！

Docker Swarm
Swarm是Docker公司在2014年12月初新发布的容器集群管理工具。它可以把多个主机变成一个虚拟的Docker主机来管理。Swarm使用Go语言开发，并且开源，在github上可以找到它的全部source code。Swarm使用标准的Docker API，给Docker用户带来无缝的集群使用体验。2016年7月， Swarm已经被整合进入Docker Engine。
功能
Docker Swarm提供API 和CLI来在管理运行Docker的集群，它的功能和使用本地的Docker并没有本质的区别。但是可以通过增加Node带来和好的扩展性。理论上，你可以通过增加节点（Node）的方式拥有一个无限大的Docker主机。
Swarm并不提供UI，需要UI的话，可以安装UCP，不过很不幸，这个UCP是收费的。
架构



Swarm的架构并不复杂，可以说非常简单。Manager负责容器的调度，Node负责容器的运行，Node运行Docker Daemon和Manager之间通过HTTP来通信。Docker Client通过Manager上暴露的标准Docker API来使用Docker的功能。
Swarm的集群协调和业务发现可以支持不同的第三方组件，包括：
Consul
Etcd
ZooKeeper
Docker Hub

如果对集群协调的概念不熟悉，可以参考我的另一篇博客《使用Python进行分布式系统协调 （ZooKeeper，Consul， etcd ）》
Swarm的基本容器调度策略有三种：
spread  容器尽可能分布在不同的节点上
binpack 容器尽可能分布在同一个节点上
random 容器分布在随机的节点上

Swarm集群的高可用配置很容易，以下图为例：



manager配置在不同的AWS AZ中，通过领导选举选出Primary manager。
多个节点分布在不同的AZ中，同时Consul／etcd／ZooKeeper也需要配成冗余的。
特点
Docker Swarm的特点是配置和架构都很简单，使用Docker原生的API，可以很好的融合Docker的生态系统。
Kubernetes
Kubernetes是Google开发的一套开源的容器应用管理系统，用于管理应用的部署，维护和扩张。利用Kubernetes能方便地管理跨机器运行容器化的应用。Kubernetes也是用Go语言开发的，在github上可以找到源代码。
Kubernetes 源于谷歌公司的内部容器管理系统Borg，经过了多年的生产环境的历炼，所以功能非常强大。
功能
Kubernetes主要提供一下的功能：
使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。

以集群的方式运行、管理跨机器的容器。

解决Docker跨机器容器之间的通讯问题。

Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

应用的高可用和靠扩展

支持应用的在线升级（Rolling Update）

支持跨云平台（IaaS）的部署

为了支持这些功能，Kubernetes做了做了很多的抽象概念，所以，刚开始使用Kubernetes，需要学习不少的新概念，包括：
Pod
Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod，通常Pod里的容器运行相同的应用，或者是相关的应用。Pod包含的容器运行在同一个Minion(Host)上，看作一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。

Job
Job是一个生命周期比较短的应用，一般只会在出错的情况下重启，可以通过配置Job的并发和运行次数来扩展Job

Service
Service是一个生命周期比较长的应用，会在任何退出时重启，可以通过配置Service的复制（Replica）来达到高扩展和高可用

Recplica Controller
Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods

以上是一些核心概念，除了这些，Kubernetes还提供其它一些概念，来支持应用程序的运维，包括：
Label
对系统中的对象通过Label的方式来管理

Namespace
对对象，资源分组，可以用于支持多租户

Config Map
提供全局的配置数据存储

总之，功能强大，系统概念繁多，比较复杂。
Kubernetes支持安装UI的addon，来管理整个系统：



架构
下图是Kubernetes的基本架构：



Master
Master定义了Kubernetes 集群Master/API Server的主要声明，Client(Kubectl)调用Kubernetes API，管理Kubernetes主要构件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等组成。
Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod，那这些资源就不能再分配给其他Pod， 除非这些Pod被删除或者退出， 因此，Kubernetes需要分析集群中所有Minion的资源使用情况，保证分发的工作负载不会超出当前该Minion节点的可用资源范围

Minion
Minion负责运行Pod，Service，Jobs， Minion通过Kubelet和Master通信。Proxy解决了外部网络能够访问跨机器集群中容器提供的应用服务。

etcd
负责集群的协调和服务发现

特点
Kubernetes提供了很多应用级别的管理能力，包括高可用可高扩展，当然为了支持这些功能，它的架构和概念都比较复杂，当然我觉得为了获得这些功能，值！
Apache Mesos
Mesos是为软件定义数据中心而生的操作系统，跨数据中心的资源在这个系统中被统一管理。Mesos的初衷并非管理容器，只是随着容器的发展，Mesos加入了容器的功能。Mesos可以把不同机器的计算资源统一管理，就像同一个操作系统，用于运行分布式应用程序。
Mesos的起源于Google的数据中心资源管理系统Borg。你可以从WIRED杂志的这篇文章中了解更多关于Borg起源的信息及它对Mesos影响。
功能
Mesos的主要功能包括：
高度的可扩展和高可用
可自定义的两级调度
提供API进行应用的扩展
跨平台

下图是Mesos的管理界面：



架构
Mesos的基本架构如下
Master
Master负责资源的统一协调和Slave的管理。 Master协调全部的Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。Mesos实现了两级调度架构，它可以管理多种类型的应用程序。第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。

Slave
Salve运行执行器（Executor）进程来运行任务。

Framework
Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。
Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务

ZooKeeper
Zookeeper负责集群的协调，Master的领导选举等

特点
Mesos相比Kubernetes和Swarm更为成熟，但是Mesos主要要解决的是操作系统级别的抽象，并非为了容器专门设计，如果用户出了容器之外，还要集成其它的应用，例如Hadoop，Spark，Kafka等，Mesos更为合适。Mesos是一个更重量级的集群管理平台，功能更丰富，当然很多功能要基于各种Framework。
Mesos的扩展性非常好，最大支持50000节点，如果对扩展性要求非常高的话么，Mesos是最佳选择。
AWS ECS
ECS （Amazon EC2 Container Service ）是亚马逊开发出的高度可扩展的高性能容器集群服务。在托管的 Amazon EC2 实例集群上轻松运行容器应用和服务。他最大的好处就是在云上，不需要自己管理数据中心的机器和网络。
功能
ECS继承了AWS服务的高扩展和高可用性，安全也可以得到保证。
在基本容器管理的基础上，ECS使用Task和Service的概念来管理应用。
Task类似Docker Compose，使用一个JSON描述要运行的应用。Service是更高一层的抽象，包含多个task的运行实例，通过修改task实例的数量，可以控制服务的伸缩。同时Service可以保证指定数量的Task在运行，当出现错误的时候，重启失败的Task
架构
下图是ECS的架构图：



使用EC2，ELB，安全组等大家熟悉的AWS的概念，AWS用户可以轻松管理你的容器集群。并且不需要付初基本资源以外的费用。
通过ECS agent可以是Container连接到ECS集群。ECS Agent使用Go开发，已开源。
我们并不清楚ECS的调度策略，但是AWS提供了一个例子，如果继承第三方的调度策略。
通过Cloud Watch Log，我们可以很方便的对整个集群进行监控。
特点
如果你是一个AWS的重度用户，ECS是个不错的选择，因为你可以是把你的容器集群运行在AWS的云上，管理起来非常方便。
比较
这里对几个平台做一个简单的比较：





总结

四个平台，Swarm是最轻量级的，功能也最简单，适于有大量Docker实例环境的用户。Kubernetes增加了很多应用级别的功能，适用于快速应用的部署和维护。Mesos最重，适用于已经有了相当的应用和容器混合的环境。ECS则推荐给AWS的用户或者不希望自己管理数据中心的云用户。
参考
巅峰对决之Swarm、Kubernetes、Mesoshttp://dockone.io/article/1138

Swarm v. Fleet v. Kubernetes v. Mesoshttps://www.oreilly.com/ideas/swarm-v-fleet-v-kubernetes-v-mesos

Container Orchestration Tools: Compare Kubernetes vs Docker Swarmhttps://platform9.com/blog/compare-kubernetes-vs-docker-swarm/

Container Orchestration Tools: Compare Kubernetes vs Mesoshttps://platform9.com/blog/compare-kubernetes-vs-mesos/

Compare Kubernetes vs ECS (Amazon EC2 Container Service)https://platform9.com/blog/compare-kubernetes-vs-ecs/

Evaluating Container Platforms at Scalehttps://medium.com/on-docker/evaluating-container-platforms-at-scale-5e7b44d93f2c#.tz8ah0ltn

Docker Swarm Wins Scaling Benchmark but Don’t Take That as Gospelhttp://thenewstack.io/docker-swarm-wins-scaling-benchmark-dont-take-gospel/