Kubernetes,Mesos和Swarm:Rancher编排引擎的比较

ValWoolcock 7年前
   <p>【编者的话】Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能。Mesos是Apache下的开源分布式资源管理框架,它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的,后在推ter得到广泛使用。Swarm是Docker公司在2014年12月初新发布的容器管理工具。和Swarm一起发布的Docker管理工具还有Machine以及Compose。我们来看下Rancher对它们有什么评价</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/59e2a239e3e6ae3ca9f8cc5c4da5e20e.png"></p>    <p>Rancher最新的版本在原有官方标准编排工具Cattle的基础上,新增支持其他几种常用的编排引擎。新增支持的编排引擎包括Swarm(Docker未来本地编排引擎)、Kubernetes和Mesos,它们都是Docker社区中最广泛使用的编排系统,满足用户不同梯度的使用性和特性。尽管Docker是既定事实上的行业容器标准,但是在容器编排上还没有绝对的赢家。这篇文章中我们我们主要介绍三种编排工具的特性,以及适应的场景。</p>    <p>目前Docker原生编排还处于初期阶段,但是新的特性在快速迭代增加中。由于原生的编排工具是官方系统的一部分,因此它成为众多开发者的默认首选编排工具,顺理成章地最有可能成为最受社区欢迎支持的工具。Kubernetes是谷歌支持的容器编排工具,它在众多容器编排工具中用的最广泛的一个。最近,Mesos和Mesosphere(Marathon的开源版)把更多的精力放在服务管理,将更多的功能留给可插拔插件和应用程序管理。这样的话,就使得应用最终容易容易定制部署,因为单个的程序更容易被更新,定制化。然而,这也意味着我们必须要修改一些设置来适配。Kubernetes更关注的是如何构建集群和在常见场景中用例的通用系统集成。</p>    <h2>Docker Native Orchestration</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6b9090af2854b5a424888f3cdc6b9f64.png"></p>    <h3>基础架构</h3>    <p>Docker 1.12引擎中附带了原生的编排工具,对独立的Docker Swarm来说是一种替代。Docker本地集群(Swarm)包涵一系列节点(Docker进程/守护进程),他们同时管理集群及提供工作服务。你可以在容器中启动工作进程也可以启动管理进程维护集群的状态。多管理模式保证了系统的高可用性,但是不推荐超过7个以上管理员用户。内部通过 RAFT算法 实现主从的一致性。与所有一致性的算法是一样的,多管理中心达到一致性的实现。实际上保持内部管理的一致也意味着Docker本地的编排不依赖外部资源,这样也是集群的管理变得更加容易。</p>    <h3>可用性</h3>    <p>Docker本机使用单节点Docker的概念,并将它们扩展到Swarm。如果你使用最新的Docker版本,那么学习曲线还是相当平缓的。一旦你想添加已经在多节点运行的Docker到Swarm中,Swarm的设置是很简单的:你只需在其中一个节点上调用docker swarm init,然后在任何其他你想添加的节点上调用docker swarm join即可。您也可以使用相同的Docker Compose模板和相同的Docker CLI命令集设计单一的Docker。</p>    <h3>功能集</h3>    <p>Docker本地可以使用与Docker Engine和Docker Compose相同的语法提供编排支持。你仍然可以链接到服务,创建卷,定义开放的端口号。所有的这些操作都适用于单个的节点,除了这些新增了两个新的概念:服务和网络。</p>    <p>Docker服务是您的节点上启动的一组容器,并且保持这些批量的容器运行。如果其中一个容器停止,它将被自动替换掉。其中服务分类两类:复制和全局。复制服务在集群中维护指定数量的容器,因为全局服务在每个集群节点上运行一个实例。要创建复制服务,请使用下面的命令:</p>    <pre>  docker service create          \    –name frontend              \    –replicas 5                 \    -network my-network         \    -p 80:80/tcp nginx:latest.  </pre>    <p>现在可以使用docker network create –driver overlay NETWORK_NAME创建命名为overlay的网络。使用overlay网络我们可以创建一个孤立、扁平、加密的虚拟网络环境用来启动容器。你可以使用约束和标签来做一些非常基本的容器调度。使用约束可以向服务添加关联,并且它将尝试仅启动具有特殊标签的容器。</p>    <pre>  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.  </pre>    <p>此外,你可以使用保留的CPU和保留的内存空间标志来定义服务的每个容器使用的资源,以便在swarm上启动多个服务时,容器可以处理最小的资源竞争。</p>    <p>你可以使用以下命令进行初步的部署。这样将会更新容器的镜像,但是两个容器之间有10s的间隔来更新两个容器。然而,health-checks和自动回滚都不支持。</p>    <pre>  docker service update        \    –name frontend            \    –replicas 5               \    -network my-network       \    --update-delay 10s        \    --update-parallelism 2    \    -p 80:80/tcp nginx:other-version.  </pre>    <p>Docker使用卷驱动程序支持外部卷持久化,并且使用mount服务命令扩展器使用。执行以下代码段将会将NFS装入到您的容器中。请注意,这需要在Docker外部的底层主机上设置NFS。在没有主机支持的情况下,其他对Amazon EBS卷或Google容器引擎卷驱动程序也能够工作。此外,这个功能还没有完善的文档,可能需要需要在github的docker项目上创建issues得到交流回复。</p>    <pre>  --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  </pre>    <h2>Kubernetes</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/87410d4bf0672588aa417bcd42be2397.png"></p>    <h3>基础架构</h3>    <p>从概念上讲,Kubernetes有点类似于Swarm,它使用一个带有RAFT的管理器(主)节点来达成一致。然而,相似的地方也只有这么多了。 Kubernetes使用外部etcd集群为此目的。此外,你将需要Kubernetes外部的网络层,这样overlay 网络就行编织法兰绒外衣一样。使用这些外部工具,您可以启动Kubernetes主组件; API服务器,控制器管理器和调度程序。这些通常作为主节点上的Kubernetes pod运行。除了这些,你还需要在每个节点上运行kubelet和kubeproxy。如果需要的话,工作节点只运行Kubelet和Kubeproxy以及像一个包装一样作为网络层提供者。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/e4cbd9a925b4279925ac029f341d8ac4.png"></p>    <p>在这个设置中,kubelet将控制给定节点上的容器(或者pod)与主控制器上的控制器管理器。主节点上的调度器负责资源分配和平衡,并且将帮助在具有最多可用资源的工作节点上放置容器。 API控制器是您的本地kubectl CLI将向集群发出命令的地方。最后,kubeproxy用于为Kubernetes中定义的服务提供负载平衡和高可用性。</p>    <h3>可用性</h3>    <p>从头开始设置Kubernetes是一个不平凡的努力,因为它需要设置etcd,网络插件,DNS服务器和证书颁发机构。从头开始设置Kubernetes的详细信息可以在这里,但幸运的是Rancher为我们完成所有这些设置。我们在 前面的文章 中介绍了如何设置Kubernetes集群。</p>    <p>除了初始设置,Kubernetes仍然有一些陡峭的学习曲线,因为它使用自己的术语和概念。 Kubernetes使用资源类型,如Pods,部署,复制控制器,服务,守护进程集等来定义部署。这些概念不是Docker专门词汇的一部分,因此您需要在开始创建第一个部署之前熟悉它们。此外,一些命名与Docker冲突。例如,Kubernetes服务不是Docker服务,也是概念上不同的(Docker服务更贴近地映射到Kubernetes世界中的Deployments)。此外,您使用kubectl而不是docker CLI与集群交互,并且必须使用Kubernetes配置文件而不是docker compose文件。</p>    <p>Kubernetes有这样一套详细的概念独立于core Docker,这本身不是一件坏事。 Kubernetes提供比core Docker更丰富的功能集。然而,Docker将添加更多的功能来与Kubernetes竞争,具有不同的实现和不同或冲突的概念。这将几乎肯定重复CoreOS / rkt情况,大部分社区在类似但竞争的解决方案。今天,Docker Swarm和Kubernetes定位于不同的使用场景(Kubernetes更适合于使用专用集群管理团队的面向服务的架构的大型生产部署),但是随着Docker 本地编排的成熟,它将迁移到这个空间。</p>    <h3>功能集</h3>    <p>Kubernetes的完整功能集太大,这篇文章不能涵盖完整,但我们将介绍一些基本概念和一些有趣的区分。首先,Kubernetes使用Pods的概念作为基本单位,而不是单个容器。每个pod是一组容器(集合大小可以是一个),它们总是在同一节点上启动,共享相同的卷并分配一个虚拟IP(VIP),以便可以在集群中寻址。单个pod的Kubernetes规范文件可能如下所示:</p>    <pre>  kind: Pod    metadata:    name: mywebservice    spec:    containers:    - name: web-1-10    image: nginx:1.10    ports:    - containerPort: 80  </pre>    <p>接下来是你的部署。这些松散地映射具体到什么服务是在Docker本地编排。您可以像Docker Native中的服务一样扩展部署,部署将确保正在运行的请求数量的容器。重要的是注意部署仅类似于Docker本地中的复制服务,如Kubernetes使用守护程序集概念来支持其等效的全局调度服务。部署还支持使用HTTP或TCP可达性或自定义exec命令来确定容器/ pod是否正常的运行状况检查。部署还支持使用运行状况检查的自动回滚滚动部署,以确定每个pod部署是否成功。</p>    <pre>  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  </pre>    <p>接下来你有Kubernetes服务,它为部署提供简单的负载平衡。部署中的所有pod都将在服务进入和退出时注册,服务也抽象出多个部署,因此如果您想回滚部署,您将使用相同的服务注册两个Kubernetes部署,然后逐个添加pod同时减少pods从其他。您甚至可以进行blue-green部署,您可以一次性将服务指向新的Kubernetes部署。最后,服务对于Kubernetes集群中的服务发现也很有用,集群中的所有服务都获得VIP,并且作为docker链接样式环境变量以及通过集成的DNS服务器暴露给集群中的所有pod。</p>    <p>除了基本服务,Kubernetes支持 作业 , 调度计划 作业和 Pet Sets 。作业创建一个或多个pod,并等待它们终止。作业确保指定数量的pod成功终止。例如,您可以开始一个作业,在最后一天开始处理1小时的商业智能数据。您将启动一个包含前一天的24个pod的作业,一旦它们都运行完成,作业完成。作为名称建议的计划作业是在给定计划上自动运行的作业。在我们的例子中,我们可能使我们的BI处理器是每日计划的工作。作业非常适合向集群发出批处理工作负载,这些负载不总是需要启动的服务,而是需要运行到完成然后清理的任务。</p>    <p>Kubernetes提供给基本服务的另一个扩展是Pet Sets。Pet Sets支持状态服务工作负载,通常很难集中化。这包括数据库和实时连接的应用程序。Pet Sets为集合中的每个“Pet”提供稳定的主机名。Pet就是索引。例如,pet5将独立于pet3可寻址,并且如果第三Pet容器/ pod死掉,则它将在具有相同索引和主机名的新主机上重新启动。</p>    <p>Pet Sets还提供使用持久卷的 稳定存储 ,即如果pet1死亡并在另一个节点上重新启动,它将获得其重新安装原始数据的卷。此外,您还可以使用NFS或其他网络文件系统在容器之间共享卷,即使它们在不同的主机上启动。这解决了从单主机到分布式Docker环境转换时最有问题的问题之一。</p>    <p>Pet Sets还提供对等发现,通常可以发现其他服务(通过Docker链接等)。然而,发现服务中的其他容器是不可能的。这使得类似Cassandra和Zookeeper基于gossip协议的服务非常难以启动。</p>    <p>最后,Pet Sets提供启动和拆卸排序,这是持久、可扩展的服务,例如Cassandra。 Cassandra依赖一组种子节点,当您上下扩展服务时,必须确保种子节点是第一个启动的节点和最后一个要删除的节点。在撰写本文时,Pet Sets是Kubernetes的一大特色,因为在没有这种支持的情况下,持久的有状态工作负载几乎不可能在Docker的生产规模上运行。</p>    <p>Kubernetes还提供命名空间来隔离集群上的工作负载,保护管理和自动扩展支持。所有这些特性更意味着Kubernetes也支持大型,多样化的工作负载,Docker Swarm目前还没有准备就绪。</p>    <h2>Marathon</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/e4de360df404a4d30211443f3a5ac8ae.png"></p>    <h3>基础架构</h3>    <p>大规模集群的另一个常见的编排设置是在Apache Mesos之上运行Marathon。 Mesos是一个开源集群管理系统,支持各种工作负载数组。 Mesos由在群集中的每个主机上运行的Mesos代理组成,它向主机报告其可用资源。可以有一个或多个Mesos主机使用Zookeeper集群进行协调。在任何给定时间,主节点之一使用主选举过程是活动的。主服务器可以向任何Mesos代理发出任务,并报告这些任务的状态。虽然您可以通过API发出任务,但正常的方法是在Mesos之上使用一个框架。 Marathon是一个这样的框架,它为运行Docker容器(以及本地Mesos容器)提供支持。</p>    <h3>可用性</h3>    <p>与Swarm相比,Marathon有一个相当陡峭的学习曲线,因为它不与Docker共用大部分概念和术语。然而,马拉松并不复杂,因此比Kubernetes更容易学习。然而,管理Marathon部署的复杂性来自于它是分层在Mesos,因此有两层工具要管理。此外,Marathon的一些更高级功能(如负载平衡)仅作为在Marathon之上运行的附加框架提供。某些功能(如身份验证)只有在DC / OS上运行Marathon时才可用,而后者又在Mesos上运行 - 为堆栈添加另一层抽象。</p>    <h3>功能集</h3>    <p>要在Marathon中定义服务,您需要使用其内部JSON格式,如下所示。一个简单的定义,如下面的一个将创建一个服务,每个运行nginx容器的两个实例。</p>    <pre>  {    "id": "MyService"    "instances": 2,    "container": {    "type": "DOCKER",    "docker": {      "network": "BRIDGE",      "image": "nginx:latest"    }    }  </pre>    <p>}</p>    <p>以上定义稍微更完整的版本如下所示,我们现在添加端口映射和health check。在端口映射中,我们指定一个容器端口,这是docker容器公开的端口。主机端口定义主机公共接口上的哪个端口映射到容器端口。如果为主机端口指定0,则在运行时分配随机端口。类似地,我们可以可选地指定服务端口。服务端口用于服务发现和负载平衡,如本节后面所述。使用健康检查,我们现在可以执行滚动(默认)和 <a href="/misc/goto?guid=4959728403450562101" rel="nofollow,noindex">blue-green</a> 部署。</p>    <pre>  {    "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    }    ]  </pre>    <p>}</p>    <p>除了单一服务之外,您还可以定义Marathon应用程序组,使用嵌套树结构的服务。在组中定义应用程序的好处是能够将整个组缩放在一起。这在微服务堆栈中非常有用,其中调整单个服务可能是困难的。到目前为止,扩展假设所有服务将以相同的速率扩展,因此如果您需要一个服务的“n”个实例,您将获得所有服务的“n”个实例。</p>    <pre>  {    "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", ... }      ]    }    ]  </pre>    <p>}</p>    <p>除了能够定义基本服务之外,Marathon还可以基于指定约束来执行容器的调度,包括指定服务的每个实例必须在不同的物理主机“约束”上:[[“hostname”, “UNIQUE”]]。您可以使用cpus和mem标记来指定该容器的资源利用率。每个Mesos代理报告其总资源可用性,因此调度程序可以以智能方式在主机上放置工作负载。</p>    <p>默认情况下,Mesos依赖于传统的Docker端口映射和外部服务发现和负载平衡机制。但是,最近的测试功能添加了对使用Mesos DNS的DNS服务发现或使用Marathon LB的负载平衡的支持。 Mesos DNS 是一个在 Mesos LB 之上运行的应用程序,它查询Mesos API以获取所有正在运行的任务和应用程序的列表。然后,它为运行这些任务的节点创建DNS记录。然后,所有Mesos代理手动更新,以使用Mesos DNS服务作为其主DNS服务器。 Mesos DNS使用用于向主机注册Mesos代理的主机名或IP地址;并且端口映射可以查询为SRV记录。由于Marathon DNS在代理主机名上工作,并且主机网络端口必须被公开,因此不能发生冲突。 Mesos DNS确实提供了一种方法来为状态负载持续引用单个容器,例如我们将能够使用Kubernetes宠物集。此外,与群集中任何容器上可寻址Kubernetes VIP不同,我们必须手动将/etc/resolve.conf更新到Mesos DNS服务器集,并在DNS服务器更改时更新配置。 Marathon-lb 使用马拉松赛事总线跟踪所有服务的启动和撤销。然后,它在代理节点上启动HAProxy实例,以将流量中继到必需的服务节点。</p>    <p>Marathon还对 持久性卷 以及 外部持久卷 提供测试支持。然而,这两个特征都处于非常原始的状态。持久卷只在容器重新启动的单个节点上持久化,但是如果删除使用它们的应用程序,则会删除卷,但磁盘上的实际数据不会被删除,必须手动删除。外部卷需要DC / OS,并且当前只允许您的服务扩展到单实例。</p>    <h2>最终裁决</h2>    <p>今天我们看了Docker容器编排的三个选项:Docker Native(Swarm),Kubernetes和Mesos / Marathon。很难选择一个系统来推荐,因为最好的系统高度依赖于你的用例,规模和历史。此外,所有三个系统都在大量开发,一些涵盖的功能是测试版,可能会很快更改,删除或替换。</p>    <p>Docker Native给你提供了最快的升级,很少甚至没有供应商的封闭超出了对Docker的依赖。对Docker的依赖不是一个大问题,因为它已经成为了实际上容器标准。鉴于在编排战争中缺乏明确的赢家,而且Docker本机是最灵活的方法,因此它是简单的web/stateless应用程序的不错选择。但是,Docker Native目前还只是一个架子,如果你需要得到复杂的,大规模的应用程序到生产,你需要选择一个Mesos / Marathon或Kubernetes。</p>    <p>在Mesos / Marathon和Kubernetes之间也不是一个容易的选择,因为两者都有自己的优点和缺点。 Kubernetes肯定是更丰富和成熟的两个,但它也是一个非常有见地的软件。我们认为很多这些意见是有意义的,但Kubernetes没有马拉松的灵活性。这是有道理的,当你考虑非Docker,非容器化的应用程序,可以运行在Mesos除了Marathon(例如Hadoop集群)的丰富的历史。如果你正在做一个绿色领域实施,也没有强烈的意见,如何布局集群,或你的意见同意谷歌,那么Kubernetes是一个更好的选择。相反,如果你有大的,复杂的遗留工作负载,将逐渐转移到容器,那么Mesos / Marathon是要走的路。</p>    <p>另一个问题是规模:Kubernetes已经测试了数千个节点,而Mesos已经测试了成千上万的节点。如果您正在启动具有数万个节点的集群,则需要使用Mesos来获得底层基础架构的可扩展性 - 但请注意,将高级功能(例如负载平衡)扩展到该范围仍将保留。然而,在那个规模,很少(如果有的话)现成的解决方案工作作为广告,没有仔细调整和猴子修补。</p>    <p> </p>    <p> </p>    <p>来自:http://dockone.io/article/1882</p>    <p> </p>