对比剖析Swarm Kubernetes Marathon编排引擎

Docker Native Orchestration

基本结构

Docker Engine 1.12 集成了原生的编排引擎，用以替换了以前独立的Docker Swarm项目。Docker原生集群（Swarm）同时包括了（Docker Engine \/ Daemons），这使原生docker能够任意充当集群的管理(manager)或工做（worker)节点角色。工做节点 （worker) 将负责执行运行你启动的容器任务，而管理节点从用户那里得到任务说明，负责整合现有的集群，维护集群状态。而且您能够有推荐的数量不超过七我的管理节点以支持高可用。管理节点会保障集群内部环境状态的强一致性，它们基于 Raft协议实现状态一致及备份 ，与全部一制性算法同样，拥有更多manager管理节点（ manager ）意味着更多的性能开销，同时在manager节点内部保持一致性的事实让你在Docker原生编排没有外部依赖性，集群管理更容易。

可用性

Docker将单节点Docker的使用概念扩展到Swarm集群。若是你熟悉docker那你学习swarm至关容易。你也能够至关简单将docker环境到迁移到运行swarm集群，（译者按：若是现有系统使用Docker Engine，则能够平滑将Docker Engine切到Swarm上，无需改动现有系统）。

你只须要在其中的一个docker节点运行使用 docker swarm init命令建立一个集群，在您要添加任何其余节点，经过docker swarm join命令加入到刚才建立的集群中。以后您能够象在一个独立的docker环境下同样使用一样的Docker Compose的模板及相同的docker命令行工具。

功能集

Docker Native Orchestration 使用与Docker Engine和Docker Compose来支持。您仍然可使用象原先在单节点同样的连接（link)，建立卷(volume)和定义公开端口(expose）功能。 除了这些，还有两个新的概念，服务（ services ）和网络（ networks ）。

docker services （服务）是管理在节点上启动的必定数量的始终保持运行的一组容器，而且若是其中一个容器死了，它支持自动更换。有两种类型的服务，复制（replicated）或全局（global）。 复制（replicated）服务在集群中维护指定数量的容器（意味着这个服务能够随意 scale），全局（global）服务在每一个群集节点上运行容器的一个实例（译者按：很少, 也很多）。 要建立复制（replicated）服务，请使用如下命令。

docker service create \
 –name frontend \
 –replicas 5 \
 -network my-network \
 -p 80:80/tcp nginx:latest.

您可使用docker network create–driver overlay NETWORK_NAME 建立命名的overylay网络。使用指定的overylay网络，您能够在你的容器内建立孤立（isolated）的，平面化的（flat），加密（encrypted）的跨节点的主机虚拟网络。

你可使用constraints加labels 来作一些基础的容器调度工做。 使用constraints 参数您能够向服务添加关联有指定标签的节点上启动容器。

docker service create \
 –name frontend \
 –replicas 5 \
 -network my-network \
 --constraint engine.labels.cloud==aws \
 --constraint node.role==manager \
 -p 80:80/tcp nginx:latest.

此外，您可使用 reserve CPU 和reserve memory标记来定义服务中的每一个容器使用的资源量，以便在群集上启动多个服务时，以最小化资源争用放置容器（译者按：容器会被部署到最适合它们的位置，最少的容器运行，最多的CPU或者内存可用，等等)。

--limit-cpu value Limit CPUs (default 0.000) \
 --limit-memory value Limit Memory (default 0 B) \
 --reserve-cpu value Reserve CPUs (default 0.000) \
 --reserve-memory value Reserve Memory (default 0 B)

您可使用如下命令进行基本的滚动部署。这将更新服务的容器镜像，但这样作，每次2个容器，每两组之间有10s的间隔。可是不支持运行情况检查和自动回滚。

docker service update \
 –name frontend \
 –replicas 5 \
 -network my-network \
 --update-delay 10s \
 --update-parallelism 2 \
 -p 80:80/tcp nginx:other-version.

Docke 支持使用卷驱动( volume drivers )程序支持持久性卷挂载，而且使用Native orchestration 为其service create命令扩展支持了mount选项。 将如下代码段添加到上面的命令将会将NFS挂载到您的容器中。请注意这须要在Docker外部的主机上已经设置好NFS，一些其余驱动程序添加了对Amazon EBS卷驱动程序或Google容器引擎卷驱动程序的支持可以在不须要主机设置的状况下工做。 此外，这个由于这些功能尚未很好的文档，可能须要一些测试并参考github issue以在docker项目获得运行。

--mount type=volume,src=/path/on/host,volume-driver=local, \
 dst=/path/in/container,volume-opt=type=nfs, \
 volume-opt=device=192.168.1.1:/your/nfs/path

Kubernetes

基本结构

从概念上讲，Kubernetes相似于Swarm的惟一点就是它也使用一个RAFT的Master节点来保证强一制性。同时为达成目的Kubernetes采用了ETCD。此外它将使用一个外部的扩展的网络层，是像overlay ，weave网络等。使用这些外部工具，您能够启动Kubernetes主要的组件; 象API服务器（API Server），控制器管理器（Controller Manager）和调度程序（Scheduler），这些一般做为Kubernetes pod在主（master）节点上运行。除了这些，你还须要在每一个节点(node)上运行kubelet和kubeproxy。工做节点（Worker nodes）只运行Kubelet和Kubeproxy以及一个网络层提供者象是flanneld。

在以上设置中，kubelet的主要功能就是获取节点上 pod\/container 的指望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），kubelet将使用主（master)节点上的controller manager操做指定的节点上 pod\/containers。调度器(scheduler)负责资源分配和平衡资源，在具备最多可用资源的工做节点(worker node)上放置容器。 API控制器负责您的本地kubectl CLI将向集群发出命令。 最后，kubeproxy组件用于为Kubernetes中定义的服务提供负载平衡和高可用性。

可用性

从头开始设置Kubernetes是一个困难的过程，由于它须要设置etcd，网络插件，DNS服务器和证书颁发机构一系统操做。 从头开始创建Kubernetes的详细文档您可浏览这里，但幸运的是在Rancher已经集成作好这一切的设置。在以前的文章中咱们已经有过介绍如何在Rancher中设置 kubernetes。

除了初始设置，Kubernetes仍然有一些陡峭的学习曲线，由于它使用本身的术语和概念。Kubernetes使用资源类型，如Pods、Deployments、Replication Controllers、Services、Daemon sets等来定义部署。 这些概念都不是Docker词典的一部分，所以您须要在开始建立第一个部署以前熟悉它们。 此外，其中的一些概念与Docker冲突， 例如Kubernetes Services 概念上并不等同于Docker Services ，（Docker Services更贴近地映射到Kubernetes世界中的Deployments) ，还有您使用kubectl而不是docker CLI与来用于群集交互， 同时您还必须使用Kubernetes配置文件，而不是docker compose文件。

Kubernetes有这样一套独立于核心Docker的概念自己并非一件坏事。 Kubernetes提供比Docker更丰富的功能集。 然而，Docker也在迅速将添加更多的功能来与Kubernetes竞争，它们具备不一样的实现方式及冲突的概念。这将确定致使重现象CoreOS与rkt之间这种相似功能但竞争的解决方案状况。 但今天来看，Docker Swarm和Kubernetes的目标仍是很是不一样的用例（Kubernetes更适合于使用于有专门的集群管理团队的面向服务的架构的大型生产部署），然而随着Docker Native Orchestration的成熟，与它同台竞争的时刻必定会到来。

功能集

Kubernetes的完整功能集太大了，不能涵盖在本文中，但咱们将讨论一些基本概念和一些有趣的区别。 首先，Kubernetes使用Pods的概念做为其缩放的基本单位，而不是单个容器。 每一个pod是一组容器（设置能够是1），这一组容器它们老是在同一节点上启动，共享相同的卷并分配一个虚拟IP（VIP），以便它们能够在集群中寻址。 单个pod的Kubernetes规范文件以下所示。

kind: Pod
 metadata:
 name: mywebservice
 spec:
 containers:
 - name: web-1-10
 image: nginx:1.10
 ports:
 - containerPort: 80

接下来展开 Deployment 设置，这些松散映射服务到Docker原生编排。您能够像Docker Native中的服务同样扩展部署运行请求数量的容器。须要的是注意，Deployment仅相似于Docker本地中的复制服务，如Kubernetes使用守护程序集概念（ Daemon Set） 来支持其等效的全局调度（globally scheduled）服务。部署还支持使用HTTP或TCP可达性或自定义exec命令进行情况检查以肯定 容器\/pod运行是否正常，同时支持使用运行情况检查的自动回滚部署，以保障每一个pod部署成功。

kind: Deployment
 metadata:
 name: mywebservice-deployment
 spec:
 replicas: 2 # We want two pods for this deployment
 template:
 metadata:
 labels:
 app: mywebservice
 spec:
 containers:
 - name: web-1-10
 image: nginx:1.10
 ports:
 - containerPort: 80

接下来它为部署提供简单的负载平衡。 部署中的全部pod将在服务进入和退出时注册到服务（service)，service 也抽象出多个Deployment，所以若是您想运行滚动部署，您将使用相同的service注册两个Kubernetes Deployment，而后逐步将pod添加到其中一个的同时从其余Deployment减小pod。 您甚至能够进行蓝绿部署，在那里您能够一次性将服务指向新的Kubernetes Deployment。 最后，服务对您的Kubernetes集群中的服务发现也颇有用，集群中的全部服务都得到VIP，而且象docker link 风格的环境变量很好的集成的DNS服务器暴露给集群中的全部pod。

除了基本的服务，Kubernetes支持Jobs, Scheduled Jobs, and Pet Sets，Jobs建立一个或多个pod，并等待直到它们终止。做业确保你有指定数量的pod完成做业。例如，您能够开始一个做业（job)，在最后一天开始处理1小时的商业智能数据。它将启动一个包含前一天的24个pod的做业，一旦它们都运行完成，做业才完成。scheduled job名称暗示了计划做业是在给定计划之上自动运行的做业。在咱们的例子中，咱们可能使咱们的BI处理器是每日计划的工做。 scheduled 做业很是适合向集群发出批量处理风格的工做负载，这些负载不是老是一直启动的服务，而是须要运行完成而后自动清理的任务。

Kubernetes提供给基本服务的另外一个扩展是Pet Sets，（编者按：它是 Kubernetes 1.3 引入的对象类型，目的是改善对有状态服务的支持）。Pet Sets支持一般很是难以容器化的有状态服务的工做负载。这包括数据库和有实时性链接需求的应用程序。Pet Sets为集合中的每一个“Pet”提供稳定的主机名设置。Pet是可被索引; 例如，pet5将独立于pet3可寻址，而且若是pet3容器\/pod死掉，则它将使用相同索引信息（index)和主机名(hostname)的新主机上从新启动。

Pet Sets还提供了稳定的存储持久卷，也就是说，若是PET1死亡，它将从新启动在另外一个节点并从新挂载原来数据卷。此外，您还可使用NFS或其余网络文件系统在容器之间共享卷，即便它们在不一样的主机上启动。这解决了从单主机到分布式Docker环境转换时最困难的问题之一。

Pet Sets还提供对等体发现（peer-discovery），一般的服务，你能够发现其余服务（经过Docker link等），然而，发现服务内的其余容器是不可能的。这使得基于gossip协议的服务，如Cassandra和Zookeeper很是难以启动。

最后，Pet Sets提供启动和排序，这是持久，可扩展的服务如Cassandra的必要条件。Cassandra依赖一组种子节点，当您扩展服务时，必须确保种子节点是第一个启动的节点和最后一个要删除的节点。在撰写本文时，Pet Sets是Kubernetes的一大特点，由于在没有这种支持的状况下，持久的有状态工做负载几乎不可能在Docker的生产规模上运行。

Kubernetes还在群集级别上提供了命名空间（namespaces），隔离工做负载的安全管理（secrets management）和自动扩展（auto-scaling）支持。 全部这些特性更意味着Kubernetes也支持大型，多样化的工做负载，Docker Swarm目前尚未这些特性。

马拉松（Marathon）

基本结构

大规模集群的另外一个常见的编排设置选择是在Apache Mesos之上运行Marathon。Mesos是一个开源集群管理系统，支持各类各样主机上的工做负载。Mesos在群集中的每一个主机上运行的Mesos代理，向master主机报告其可用资源。 Mesos 利用多台 Mesos master 来实现高可用性（high-availability），包括一个活跃的 master （译者按：叫作 leader 或者 leading master）和若干备份 master 来避免宕机。 经过 Apache ZooKeeper 选举出活跃的 leader，而后通知集群中的其余节点，包括其余Master，slave节点和调度器（scheduler driver）。在任什么时候间，master节点之一使用主选举过程是活动着的。master能够向任何Mesos agent发出任务，并报告这些任务的状态。虽然您能够经过API发出任务，但正常的方法是在Mesos之上使用一个framework框架。Marathon就是一个这样的framework框架，它为运行Docker容器（以及本地Mesos容器）提供支持。

可用性

与Swarm相比，Marathon有一个至关陡峭的学习曲线，由于它不与Docker分享大部分概念和术语。然而，马拉松（ Marathon ）功能并不丰富，所以比起Kubernetes更容易学习。管理Marathon部署的复杂性主要来自于它是架构在Mesos之上的事实，所以有两层工具要管理。此外， 马拉松 (Marathon)的一些更高级功能（如负载平衡）仅支持在Marathon之上运行的附加框架提供。 某些功能（如身份验证）只有在DC\/OS上运行马拉松（Marathon时）才可以使用，然后者又在Mesos上运行 – 这为堆栈添加另外一层抽象。

功能集

要在Marathon中定义服务，您须要使用其内部JSON格式，以下所示。 一个简单的定义，以下面的一个将建立一个服务，运行两个nginx容器实例。

{
 "id": "MyService"
 "instances": 2,
 "container": {
 "type": "DOCKER",
 "docker": {
 "network": "BRIDGE",
 "image": "nginx:latest"
 }
 }
 }

一个略微更完整些的版本以下所示，咱们如今添加端口映射和健康检查。 在端口映射中，咱们指定一个容器端口，这是docker容器公开的端口。 主机端口定义主机公共接口上的哪一个端口映射到容器端口。 若是为主机端口指定0，则在运行时分配随机端口。 相似地，咱们能够可选地指定服务端口。服务端口用于服务发现和负载平衡，如本节后面所述。 使用健康检查，咱们如今既能够作滚动（默认）和蓝绿部署

{
 "id": "MyService"
 "instances": 2,
 "container": {
 "type": "DOCKER",
 "docker": {
 "network": "BRIDGE",
 "image": "nginx:latest"
 "portMappings": [
 { "containerPort": 8080, "hostPort": 0, "servicePort": 9000, "protocol": "tcp" },
 ]
 }
 },
 "healthChecks": [
 {
 "protocol": "HTTP",
 "portIndex": 0,
 "path": "/",
 "gracePeriodSeconds": 5,
 "intervalSeconds": 20,
 "maxConsecutiveFailures": 3
 }
 ]
 }

在单一服务以外，您还能够定义马拉松 (Marathon)应用程序组( Application Groups )用于嵌套树结构的服务。在组中定义应用程序的好处是可以将整个组缩放在一块儿。这是很是有用的在微服务栈场景中由于单独去调整每一个服务是相对困难的。到这一步，咱们进一步假设全部服务将以相同的速率扩展，若是您须要一个服务的“n”个实例，您将得到全部服务的“n”个实例。

{
 "id": "/product",
 "groups": [
 {
 "id": "/product/database",
 "apps": [
 { "id": "/product/mongo", ... },
 { "id": "/product/mysql", ... }
 ]
 },{
 "id": "/product/service",
 "dependencies": ["/product/database"],
 "apps": [
 { "id": "/product/rails-app", ... },
 { "id": "/product/play-app", ... }
 ]
 }
 ]
 }

在定义基本的服务以外，马拉松 （Marathon ）还能够作基于指定容器的约束条件调度，详见这里，包括指定该服务的每一个实例必须在不一样的物理主机 “constraints”: [[“hostname”, “UNIQUE”]].您可使用的CPU和mem标签指定容器的资源利用率。每一个Mesos代理报告其总资源可用性，所以调度程序能够以智能方式在主机上放置工做负载。

默认状况下，Mesos依赖于传统的Docker端口映射和外部服务发现和负载均衡机制。 而最近的测试版功能添加了使用基于DNS服务发现支持Mesos DNS或负载均衡使用Marathon LB。

Mesos DNS是一个在Mesos之上运行的应用程序，它查询Mesos API以获取全部正在运行的任务和应用程序的列表。而后，它为运行这些任务的节点建立DNS记录。以后全部Mesos代理须要手动更新使用Mesos DNS服务器做为其主DNS服务器。Mesos DNS使用主机名或IP地址用于Mesos agent向master主机注册，端口映射能够查询为SRV记录。

Marathon DNS使用agent的主机名，因此必须确保主机网络相应端口打开且不能发生冲突。Mesos DNS提供了不同凡响的方法来为有状态负载引用，例如咱们将可以结合使用Kubernetes pet sets。此外与Kubernetes有群集内任何容器可寻址的VIP机制不一样，Mesos必须手动将\/etc\/resolve.conf更新到Mesos DNS服务器集，并在DNS服务器变动时须要更新配置。 Marathon-lb使用Marathon Event bus 跟踪全部服务的启动和撤销状态。而后它在agent节点上启动HAProxy实例，以将流量中继到必需的服务节点。

马拉松（Marathon）的测试版支持持久卷，之外部持久性卷（external persistent volumes） 。然而，这两个特征都处于很是原始的状态。持久卷只支持容器在单个节点上从新启动时支持持久化数据卷，可是会删除卷若是删除使用它们的应用的时候，固然磁盘上的实际数据不会被删除，volume必须手动删除。外部持久性卷的支持则限制在必须在DC\/OS之上运行，而且当前只容许您的服务扩展到单个实例。

总结

如今咱们看了Docker容器编排的三个选项：Docker Native（Swarm），Kubernetes和Mesos\/Marathon。很难选择一个系统来推荐，由于最好的系统高度依赖于你的具体用例需求，部署规模和应用历史缘由。此外，全部三个系统如今还都在大量开发中，上面总结的一些功能中包括了测试版本，有可能会很快更改，删除或被替换。

Docker Native给你提供了最快的适应的通道，而且它不多甚至没有对Docker的依赖以外的供应商锁定问题。惟一的对Docker自己的依赖不是一个大问题，由于docker 已经成为了事实上的容器标准。鉴于在编排引擎的市场竞争中目前尚未明确的赢家，并且Docker本机是最灵活的方法，所以它是简单的Web及无状态应用程序的不错选择，可是，Docker Native目前是初始的状态，若是你须要获得复杂的，大规模的应用程序到生产，你须要选择一个Mesos\/Marathon或Kubernetes。

在Mesos\/Marathon和Kubernetes之间也不是一个容易的选择，由于二者都有本身的优势和缺点。在二者之中Kubernetes确定是更丰富和成熟的，但它也是一个很是有执拗的（有个性的）软件（译者按：Kubernetes有些执拗己见对于容器如何组织和网络强制了一些概念），咱们认为不少这些意见是有意义的。同时Kubernetes没有马拉松的灵活性，尤为当你考虑那些没有Docker，没有容器化的应用程序能够运行在Mesos（例如Hadoop集群）的丰富的历史。 若是你正在作一个绿色领域实施，也没有强烈的意向如何布局集群，或你的需求想法与谷歌相同，那么Kubernetes是一个更好的选择。相反，若是你有大的，复杂的遗留工做负载，并将逐渐转移到容器化，那Mesos\/Marathon是要走的路。

另外一个问题是规模：Kubernetes已经测试了数千个节点，而Mesos已经测试了成千上万的节点。若是您正在启动具备数万个节点的集群，则须要使用Mesos来得到底层基础架构的可扩展性 – 但请注意，将高级功能（例如负载平衡）扩展到该范围仍将保留。然而，在那个规模，不多有现成的解决方案，若是有的话它也须要不断仔细调整及不断的改造。