[TOC]
比较 Docker-Swarm、Kubernetes 和 Mesos 容器技术,虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能,但实际上它们各自解决了不同的问题,并且根植于迥异的上下文环境中,事实上这三种被广泛采用的工具链都是有差别的;
WeiyiGeek.docker-k8s-mesos
让我们重新审视每个项目的原始任务、技术架构,以及它们是如何相互补充和交互的,而不是纠结于比较这些快速迭代的技术之间重叠的特性。
当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时,他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较(即容器编排技术)。
Q:什么是容器编排技术? 答:应用一般由单独容器化的组件(通常称为微服务)组成,且必须按顺序在网络级别进行组织,以使其能够按照计划运行。以这种方法对多个容器进行组织的流程即称为容器编排。
容器编排定义 答:在现代开发当中,整体式的应用早已成为过去时,如今的应用由数十乃至数百个松散结合的容器式组件构成,而这些组件需要通过相互间的协同合作,才能使既定的应用按照设计运作。容器编排是指对单独组件和应用层的工作进行组织的流程。
容器编排的工作原理是什么? 答:虽然诸如 Apache Mesos、Google Kubernetes 以及 Docker Swarm 等平台均有其特定的容器管理方法,但所有的容器编排引擎均可让用户控制容器启动和停止的时间、将其分组合到群集中,以及协调应用组合的流程。容器编排工具允许用户指导容器部署与自动更新、运行状况监控以及故障转移等步骤。
Docker 公司始于名为 dotCloud 的平台即服务(PaaS)供应商: Docker 文件格式成为行业标准,领先的容器技术供应商(包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会Cloud Native Computing Foundation(CNCF)[9] 和 开放容器推进联盟Open Container Initiative (OCI)[10]。 如今CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口,并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行;
Docker它提供了如下功能:
随着 Docker 开始商业化其开源的文件格式(LCTT 译注:指 Docker 镜像的 dockerfile 文件格式),该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎,包括:
WeiyiGeek.docker引擎
Google 很早就认识到了 Docker 的潜力,并试图在 Google Cloud Platform (GCP)上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验(是他们在 Linux 中引入了 cgroups),但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合,所以Google 没有使用原有系统的任何代码,而是从头开始设计 Kubernetes (K8S)来编排 Docker 容器;
Kubernetes 于 2015 年 2 月发布,在2016 年 3 月Google 将 Kubernetes 捐赠给了CNCF,并且直到今天仍然是该项目的主要贡献者(其次是Redhat,CoreOS 等)。 K8S其目标和考虑如下:
WeiyiGeek.k8s架构图
Kubernetes 的优势:
Kubernets 与 docker Swarm比较? 答:Kubernetes 也是有吸引力的,因为它是 CNCF 旗下的开源项目与 Docker Swarm 相反尽管它是开源的,但是被 Docker 公司紧紧地掌控着。
Apache Mesos 始于加州大学伯克利分校UC Berkeley的下一代容器集群管理器项目,并应用了从云计算级别的分布式基础架构(如 Google 的 Borg 和 Facebook 的 Tupperware [具有单一架构])中习得的经验和教训。
Mesos 推出了一种模块化架构一种开源的开发方法,旨在完全独立于基础架构。Mesos 迅速被 Twitter[14]、Apple(Siri 中)[15]、Yelp[16]、Uber[17]、Netflix[18] 和许多领先的技术公司采用,支持从微服务、大数据和实时分析到弹性扩展的一切。
Mesos 作为集群管理器被设计用来解决一系列不同的挑战:
Mesos技术特点:
WeiyiGeek.MESOS架构-Mesos two-level scheduler
Mesos 以每一个工作负载所需的特定方式管理各种工作负载,使得许多公司将 Mesos 作为一个统一的平台,将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”(LCTT 译注:SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)
实际案例:举一个团队如何管理应用软件升级的例子。 无状态应用程序可以从“蓝/绿”[19]部署方案中受益;当新版本的应用运行起来时,原先旧版本的软件依然还正常运转着,然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次,此时需要持久化本地数据卷以防止数据丢失,并且按照特定的顺序执行原位升级,在升级之前和升级完成之后,都要在每一个节点类型上执行特定的检查和命令。 由于任何这些步骤都是应用程序或服务特定的,甚至可能是版本特定的,这让使用常规容器编排调度程序来管理数据服务变得非常困难;
Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具,Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流,以及更多其他的服务。
总而言之,所有这三种技术都与 Docker 容器有关,可以让你在容器编排上实现应用程序的可移植性和扩展性。
那么你在它们之间如何选择呢?