容器集群管理平台的比较

容器化和微服务是当前最热话题，不久之前，笔者（据说因为现在都不用笔了，“笔者”的称谓已经不合适了，因为输入用键盘，叫“键人”更为合适）参加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	Kubernetes	Mesos	ECS
基本功能	Docker原生的集群管理工具	开源的容器集群工具，提供应用级别的部署，维护和扩张功能	基于数据中心的操作系统	基于云的高可用，高扩展容器集群
高层次抽象	无	Pod Job Service	无	Task Service
应用扩展性	无	支持	Framework 支持	支持
应用高可用性	无	支持	Framework 支持	支持
集群协调和服务发现	etcd ZooKeeper Consul	etcd	ZooKeeper	／
调度策略（Schedule）	内置，可扩展	内置	两级别，可扩展	可扩展
监控	Logging Driver	Heapter，ELK Addon	内置	CloudWatch
用户界面	CLI API UCP UI	CLI API UI	API UI	CLI API AWS Console
开发语言	Go	Go	Java	NA
开源	是	是	是	否
最大支持管理节点数	官方1000 非官方5000	官方1000 非官方2000	10000	／

 

总结

四个平台，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