容器集群管理平台的比较

容器化和微服务是当前最热话题，不久之前，笔者（据说因为现在都不用笔了，“笔者”的称谓已经不合适了，因为输入用键盘，叫“键人”更为合适）参加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、Mesos

• Swarm v. Fleet v. Kubernetes v. Mesos

• Container Orchestration Tools: Compare Kubernetes vs Docker Swarm

• Container Orchestration Tools: Compare Kubernetes vs Mesos

• Compare Kubernetes vs ECS (Amazon EC2 Container Service)

• Evaluating Container Platforms at Scale

• Docker Swarm Wins Scaling Benchmark but Don’t Take That as Gospel