mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
translated
This commit is contained in:
rieonke
parent
0064e02af2
commit
12f3415224
@ -1,143 +0,0 @@
|
||||
> translating by rieonke
|
||||
Docker vs. Kubernetes vs. Apache Mesos: Why What You Think You Know is Probably Wrong
|
||||
============================================================
|
||||
|
||||
|
||||
There are countless articles, discussions, and lots of social chatter comparing Docker, Kubernetes, and Mesos. If you listen to the partially-informed, you’d think that the three open source projects are in a fight-to-the death for container supremacy. You’d also believe that picking one over the other is almost a religious choice; with true believers espousing their faith and burning heretics who would dare to consider an alternative.
|
||||
|
||||
That’s all bunk.
|
||||
|
||||
While all three technologies make it possible to use containers to deploy, manage, and scale applications, in reality they each solve for different things and are rooted in very different contexts. In fact, none of these three widely adopted toolchains is completely like the others.
|
||||
|
||||
Instead of comparing the overlapping features of these fast-evolving technologies, let’s revisit each project’s original mission, architectures, and how they can complement and interact with each other.
|
||||
|
||||
### Let’s start with Docker…
|
||||
|
||||
Docker Inc., today started as a Platform-as-a-Service startup named dotCloud. The dotCloud team found that managing dependencies and binaries across many applications and customers required significant effort. So they combined some of the capabilities of Linux [cgroups][1] and namespaces into a single and easy to use package so that applications can consistently run on any infrastructure. This package is [the Docker image][2], which provides the following capabilities:
|
||||
|
||||
* Packages the application and the libraries in a single package (the Docker Image), so applications can consistently be deployed across many environments;
|
||||
|
||||
* Provides Git-like semantics, such as “docker push”, “docker commit” to make it easy for application developers to quickly adopt the new technology and incorporate it in their existing workflows;
|
||||
|
||||
* Define Docker images as immutable layers, enabling immutable infrastructure. Committed changes are stored as an individual read-only layers, making it easy to re-use images and track changes. Layers also save disk space and network traffic by only transporting the updates instead of entire images;
|
||||
|
||||
* Run Docker containers by instantiating the immutable image with a writable layer that can temporarily store runtime changes, making it easy to deploy and scale multiple instances of the applications quickly.
|
||||
|
||||
Docker grew in popularity, and developers started to move from running containers on their laptops to running them in production. Additional tooling was needed to coordinate these containers across multiple machines, known as container orchestration. Interestingly, one of the first container orchestrators that supported Docker images (June 2014) was [Marathon][3] on Apache Mesos (which we’ll describe in more detail below). That year, Solomon Hykes, founder and CTO of Docker, recommended Mesos as “[the gold standard for production clusters][4]”. Soon after, many container orchestration technologies in addition to Marathon on Mesos emerged: [Nomad][5], [Kubernetes][6] and, not surprisingly, Docker Swarm ([now part of Docker Engine][7]).
|
||||
|
||||
As Docker moved to commercialize the open source file format, the company also started introducing tools to complement the core Docker file format and runtime engine, including:
|
||||
|
||||
* Docker hub for public storage of Docker images;
|
||||
|
||||
* Docker registry for storing it on-premise;
|
||||
|
||||
* Docker cloud, a managed service for building and running containers;
|
||||
|
||||
* Docker datacenter as a commercial offering embodying many Docker technologies.
|
||||
|
||||
|
||||
|
||||
Source: www.docker.com.
|
||||
|
||||
Docker’s insight to encapsulate software and its dependencies in a single package have been a game changer for the software industry; the same way mp3’s helped to reshape the music industry. The Docker file format became the industry standard, and leading container technology vendors (including Docker, Google, Pivotal, Mesosphere and many others) formed the [Cloud Native Computing Foundation (CNCF)][8] and [Open Container Initiative (OCI)][9]. Today, CNCF and OCI aim to ensure interoperability and standardized interfaces across container technologies and ensure that any Docker container, built using any tools, can run on any runtime or infrastructure.
|
||||
|
||||
### Enter Kubernetes
|
||||
|
||||
Google recognized the potential of the Docker image early on and sought to deliver container orchestration “as-a-service” on the Google Cloud Platform. Google had tremendous experience with containers (they introduced cgroups in Linux) but existing internal container and distributed computing tools like Borg were directly coupled to their infrastructure. So, instead of using any code from their existing systems, Google designed Kubernetes from scratch to orchestrate Docker containers. Kubernetes was released in February 2015 with the following goals and considerations:
|
||||
|
||||
* Empower application developers with a powerful tool for Docker container orchestration without having to interact with the underlying infrastructure;
|
||||
|
||||
* Provide standard deployment interface and primitives for a consistent app deployment experience and APIs across clouds;
|
||||
|
||||
* Build on a Modular API core that allows vendors to integrate systems around the core Kubernetes technology.
|
||||
|
||||
By March 2016, Google [donated Kubernetes][10] to CNCF, and remains today the lead contributor to the project (followed by Redhat, CoreOS and others).
|
||||
|
||||
|
||||
|
||||
Source: wikipedia
|
||||
|
||||
Kubernetes was very attractive for application developers, as it reduced their dependency on infrastructure and operations teams. Vendors also liked Kubernetes because it provided an easy way to embrace the container movement and provide a commercial solution to the operational challenges of running your own Kubernetes deployment (which remains a non-trivial exercise). Kubernetes is also attractive because it is open source under the CNCF, in contrast to Docker Swarm which, though open source, is tightly controlled by Docker, Inc.
|
||||
|
||||
Kubernetes’ core strength is providing application developers powerful tools for orchestrating stateless Docker containers. While there are multiple initiatives to expand the scope of the project to more workloads (like analytics and stateful data services), these initiatives are still in very early phases and it remains to be seen how successful they may be.
|
||||
|
||||
### Apache Mesos
|
||||
|
||||
Apache Mesos started as a UC Berkeley project to create a next-generation cluster manager, and apply the lessons learned from cloud-scale, distributed computing infrastructures such as [Google’s Borg][11] and [Facebook’s Tupperware][12]. While Borg and Tupperware had a monolithic architecture and were closed-source proprietary technologies tied to physical infrastructure, Mesos introduced a modular architecture, an open source development approach, and was designed to be completely independent from the underlying infrastructure. Mesos was quickly adopted by [Twitter][13], [Apple(Siri)][14], [Yelp][15], [Uber][16], [Netflix][17], and many leading technology companies to support everything from microservices, big data and real time analytics, to elastic scaling.
|
||||
|
||||
As a cluster manager, Mesos was architected to solve for a very different set of challenges:
|
||||
|
||||
* Abstract data center resources into a single pool to simplify resource allocation while providing a consistent application and operational experience across private or public clouds;
|
||||
|
||||
* Colocate diverse workloads on the same infrastructure such analytics, stateless microservices, distributed data services and traditional apps to improve utilization and reduce cost and footprint;
|
||||
|
||||
* Automate day-two operations for application-specific tasks such as deployment, self healing, scaling, and upgrades; providing a highly available fault tolerant infrastructure;
|
||||
|
||||
* Provide evergreen extensibility to run new application and technologies without modifying the cluster manager or any of the existing applications built on top of it;
|
||||
|
||||
* Elastically scale the application and the underlying infrastructure from a handful, to tens, to tens of thousands of nodes.
|
||||
|
||||
Mesos has a unique ability to individually manage a diverse set of workloads — including traditional applications such as Java, stateless Docker microservices, batch jobs, real-time analytics, and stateful distributed data services. Mesos’ broad workload coverage comes from its two-level architecture, which enables “application-aware” scheduling. Application-aware scheduling is accomplished by encapsulating the application-specific operational logic in a “Mesos framework” (analogous to a runbook in operations). Mesos Master, the resource manager, then offers these frameworks fractions of the underlying infrastructure while maintaining isolation. This approach allows each workload to have its own purpose-built application scheduler that understands its specific operational requirements for deployment, scaling and upgrade. Application schedulers are also independently developed, managed and updated, allowing Mesos to be highly extensible and support new workloads or add more operational capabilities over time.
|
||||
|
||||
|
||||
|
||||
Take, for example, how a team manages upgrades. Stateless application can benefit from a [“blue/green”][18] deployment approach; where another complete version of the app is spun up while the old one is still live, and traffic switches to the new app when ready and the old app is destroyed. But upgrading a data workload like HDFS or Cassandra requires taking the nodes offline one at a time, preserving local data volumes to avoid data loss, performing the upgrade in-place with a specific sequence, and executing special checks and commands on each node type before and after the upgrade. Any of these steps are app or service specific, and may even be version specific. This makes it incredibly challenging to manage data services with a conventional container orchestration scheduler.
|
||||
|
||||
Mesos’ ability to manage each workload the way it wants to be treated has led many companies to use Mesos as a single unified platform to run a combination of microservices and data services together. A common reference architecture for running data-intensive applications is the “[SMACK stack][19]”.
|
||||
|
||||
### A Moment of Clarity
|
||||
|
||||
Notice that we haven’t said anything about container orchestration to describe Apache Mesos. So why do people automatically associate Mesos with container orchestration? Container orchestration is one example of a workload that can run on Mesos’ modular architecture, and it’s done using a specialized orchestration “framework” built on top of Mesos called Marathon. Marathon was originally developed to orchestrate app archives (like JARs, tarballs, ZIP files) in [cgroup][20]containers, and was one of the first container orchestrators to support Docker containers in 2014.
|
||||
|
||||
So when people compare Docker and Kubernetes to Mesos, they are actually comparing Kubernetes and Docker Swarm to Marathon running on Mesos.
|
||||
|
||||
Why does this matter? Because Mesos frankly doesn’t care what’s running on top of it. Mesos can elastically provide cluster services for Java application servers, Docker container orchestration, Jenkins CI Jobs, Apache Spark analytics, Apache Kafka streaming, and more on shared infrastructure. Mesos could even run Kubernetes or other container orchestrators, though a public integration is not yet available.
|
||||
|
||||
|
||||
|
||||
Source: Apache Mesos Survey 2016
|
||||
|
||||
Another consideration for Mesos (and why it’s attractive for many enterprise architects) is its maturity in running mission critical workloads. Mesos has been in large scale production (tens of thousands of servers) for more than 7 years, which is why it’s known to be more production ready and reliable at scale than many other container-enabling technologies in the market.
|
||||
|
||||
### What does this all mean?
|
||||
|
||||
In summary, all three technologies have something to do with Docker containers and give you access to container orchestration for application portability and scale. So how do you choose between them? It comes down to choosing the right tool for the job (and perhaps even different ones for different jobs). If you are an application developer looking for a modern way to build and package your application, or to accelerate microservices initiatives, the Docker container format and developer tooling is the best way to do so.
|
||||
|
||||
If you are a dev/devops team and want to build a system dedicated exclusively to Docker container orchestration, and are willing to get your hands dirty integrating your solution with the underlying infrastructure (or rely on public cloud infrastructure like Google Container Engine or Azure Container Service), Kubernetes is a good technology for you to consider.
|
||||
|
||||
If you want to build a reliable platform that runs multiple mission critical workloads including Docker containers, legacy applications (e.g., Java), and distributed data services (e.g., Spark, Kafka, Cassandra, Elastic), and want all of this portable across cloud providers and/or datacenters, then Mesos (or our own Mesos distribution, Mesosphere DC/OS) is the right fit for you.
|
||||
|
||||
Whatever you choose, you’ll be embracing a set of tools that makes more efficient use of server resources, simplifies application portability, and increases developer agility. You really can’t go wrong.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/?from=timeline&isappinstalled=0&nsukey=b2Ig6wj1rvlgVuEZ8ens0KVLuxYx7zv7GLuL1KBpcSWpvkfF2nHcSqeKJ7JnP%2FckIM4vBaRUkwdlUpWHNzrY8va0G14sN323y7T7OEix0DZpQOUQ%2FeiRcA7wJWN3Rws4PVSSI0wapm%2Bl5jCf%2B%2Bbj5HioS%2B%2FOeeil79KMIFrgFjKRMRWwZvlbOyq4j4iaipOi
|
||||
|
||||
作者：[Amr Abdelrazik ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://mesosphere.com/blog/author/amr-abdelrazik/
|
||||
[1]:https://en.wikipedia.org/wiki/Cgroups
|
||||
[2]:https://docs.docker.com/engine/docker-overview/
|
||||
[3]:https://mesosphere.github.io/marathon/
|
||||
[4]:https://www.google.com/url?q=https://www.youtube.com/watch?v=sGWQ8WiGN8Y&feature=youtu.be&t=35m10s&sa=D&ust=1500923856666000&usg=AFQjCNFLtW96ZWnOUGFPX_XUuVOPdWrd_w
|
||||
[5]:https://www.nomadproject.io/
|
||||
[6]:http://kubernetes.io/
|
||||
[7]:https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/
|
||||
[8]:https://www.cncf.io/
|
||||
[9]:https://www.opencontainers.org/
|
||||
[10]:https://www.linuxfoundation.org/news-media/announcements/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-0
|
||||
[11]:https://research.google.com/pubs/pub43438.html
|
||||
[12]:https://www.youtube.com/watch?v=C_WuUgTqgOc
|
||||
[13]:https://youtu.be/F1-UEIG7u5g
|
||||
[14]:http://www.businessinsider.com/apple-siri-uses-apache-mesos-2015-8
|
||||
[15]:https://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html
|
||||
[16]:http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html
|
||||
[17]:https://medium.com/netflix-techblog/distributed-resource-scheduling-with-apache-mesos-32bd9eb4ca38
|
||||
[18]:https://martinfowler.com/bliki/BlueGreenDeployment.html
|
||||
[19]:https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/
|
||||
[20]:https://en.wikipedia.org/wiki/Cgroups
|
||||
[21]:https://mesosphere.com/blog/author/amr-abdelrazik/
|
||||
@ -0,0 +1,143 @@
|
||||
Docker vs. Kubernetes vs. Apache Mesos: 为什么你认为你知道的可能是错的
|
||||
============================================================
|
||||
|
||||
有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker ，Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你还相信从他们中选出一个来几乎是一种宗教选择；真正的信徒忠于他们的信仰，烧死那些异教徒，谁还敢考虑一个替代的方案。
|
||||
|
||||
那都是废话。
|
||||
|
||||
虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具，都是有差别的。
|
||||
|
||||
让我们重新审视每个项目的原始任务，技术架构，以及他们如何相互补充和交互。而不是纠结于比较这些快速迭代的技术之间重叠的特性。
|
||||
|
||||
### 让我们从Docker开始…
|
||||
|
||||
Docker 公司, 始于名为dotCloud的平台即服务(PaaS)供应商。dotCloud团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将Linux cgroups和namespace的一些功能合并成一个单一且易于使用的包，以便于应用程序可以在任何基础设施上一致地运行。这个包就是Docker镜像。Docker镜像提供了如下的功能：
|
||||
|
||||
* 将应用程序和依赖库封装在一个包( Docker 镜像)中, 因此应用可以被一致地部署在各个环境上；
|
||||
|
||||
* 提供类似 Git 的语义, 例如“docker push”，“docker commit”等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；
|
||||
|
||||
* 定义 Docker 镜像为不可变的层, 支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；
|
||||
|
||||
* 通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例；
|
||||
|
||||
Docker 变得越来越受欢迎，开发者们开始从笔记本电脑上运行容器迁移到生产环境中。 跨多个机器之间协调这些容器需要额外的工具，称之为容器编排。有趣的是，第一个支持 Docker 镜像(2014 年 6月)的容器编排工具是 Apache Mesos(后面会有详细介绍) 的[Marathon][3]。那年，Docker的创始人兼首席技术官Solomon Hykes将Mesos推荐为“[生产集群的黄金标准][4]”。不久之后，除了Mesos 的Marathon 之外，还有出现了许多的容器编排技术：[Nomad][4]，[Kubernetes][5]，不出所料还有Docker Swarm([如今是Docker 引擎的一部分][7])。
|
||||
|
||||
随着Docker开始将其开源产品商业化，该公司还开始引入工具来补充Docker核心和运行时引擎，包括：
|
||||
|
||||
* 为存储公共Docker镜像的而生的Docker hub；
|
||||
|
||||
* 存储私有镜像的 Docker 仓库(Docker registry)；
|
||||
|
||||
* Docker cloud，用于构建和运行容器的服务；
|
||||
|
||||
* Docker 数据中心作为一种商业产品体现了许多Docker技术；
|
||||
|
||||
|
||||
|
||||
来源: www.docker.com.
|
||||
|
||||
Docker 将软件及其以来关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如mp3的出现重塑了音乐行业一般。Docker 成为行业标准，领先的容器技术供应商(包括Docker，Google，Pivotal，Mesosphere 等) 组建了 [Cloud Native Computing Foundation (CNCF)][8] 和 [Open Container Initiative (OCI)][9]。如今, CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何Docker容器都可以在任何运行时或基础架构上运行。
|
||||
|
||||
### 进入 Kubernetes
|
||||
|
||||
Google很早就认识到了Docker的潜力，并试图在Google Cloud Platform上提供容器业务流程“即服务”。 Google在容器方面拥有丰富的经验（他们在Linux中引入了cgroups），但现有的内部容器和Borg等分布式计算工具直接与其原有基础架构相耦合。所以，Google没有使用原有系统的任何代码，而是从头开始设计Kubernetes来编排Docker容器。 Kubernetes于2015年2月发布，目标和考虑如下：
|
||||
|
||||
* 为应用程序开发人员提供编排Docker容器的强大工具，而无需与底层基础设施交互;
|
||||
|
||||
* 提供标准部署接口和原语 ，以实现云端一致的应用部署体验和API;
|
||||
|
||||
* 基于模块化API核心，允许供应商围绕Kubernetes的核心技术集成其系统。
|
||||
|
||||
2016年3月，Google[将Kubernetes捐赠][10]给了CNCF，今天仍然是该项目的主要负责人（其次是Redhat，CoreOS等）。
|
||||
|
||||
|
||||
|
||||
来源: wikipedia
|
||||
|
||||
Kubernetes对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署Kubernetes（这仍然是一个非常重要的工作）提供商业解决方案。 Kubernetes也是有吸引力的，因为它是CNCF旗下的开源项目，与Docker Swarm相反，Docker Swarm尽管是开源的，但是被Docker公司紧紧地掌控着。
|
||||
|
||||
|
||||
Kubernetes的核心优势是为应用程序开发人员提供了用于编排无状态Docker容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务）。虽然这些提议仍处于非常早期的阶段，他们能取得多大的成功还有待观察。
|
||||
|
||||
### Apache Mesos
|
||||
|
||||
Apache Mesos 始于加州大学伯克利分校(UC Berkeley)的下一代容器集群管理器项目，并应用了从云计算分布式计算基础架构(如[Google的Borg][11]和[Facebook的Tupperware][12])中习得的经验和教训。 虽然Borg和Tupperware具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但Mesos推出了一种模块化架构，一种开源开发方法，旨在完全独立于基础架构。Mesos迅速被 [Twitter][13]，[Apple(Siri)][14], [Yelp][15], [Uber][16], [Netflix][17] 和许多领先的技术公司采用，支持从微服务，大数据和实时分析到弹性扩展的一切。
|
||||
|
||||
作为集群管理器，Mesos被设计用来解决一系列不同的挑战：
|
||||
|
||||
* 将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验;
|
||||
|
||||
* 在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;
|
||||
|
||||
* 为应用程序特定的任务（如部署，自我修复，扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施;
|
||||
|
||||
* 提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序;提供常规的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序;
|
||||
|
||||
* 弹性扩展，将应用程序和底层基础设施从少量扩展到数十到数万个节点。
|
||||
|
||||
|
||||
Mesos独有的独立管理各种工作负载的能力 - 包括传统应用程序，如Java，无状态Docker微服务，批处理作业，实时分析和有状态的分布式数据服务。Mesos广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。 通过将应用程序特定的操作逻辑封装在“Mesos框架”（类似于操作中的运行手册）中来实现应用程序感知调度。资源管理器Mesos Master提供这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署，扩展和升级的特定操作要求。 应用程序调度程序也是独立开发，管理和更新的，这让Mesos拥有高可扩展的能力，支持新的工作负载或随着时间的推移增加更多的操作功能。
|
||||
|
||||
|
||||
|
||||
举一个例子，团队如何管理应用软件升级。 无状态应用程序可以从[“蓝/绿”][18]部署方案中受益；当新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次，此时需要持久化本地数据以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。 这让使用常规容器编排调度程序来管理数据服务变得非常困难。
|
||||
Mesos以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将Mesos作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是[“SMACK”][19](译者按：SMACK即Spark，Mesos，Akka，Cassandra，Kafka)。
|
||||
|
||||
### 是时候搞清楚这些了
|
||||
|
||||
请注意，我们尚未对Apache Mesos的容器编排有任何描述。所以为什么人们会自动地将Mesos和容器编排联系起来呢？容器编排是可以在Mesos的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就Marathon，一个构建于Mesos之上的工具。 Marathon最初是为了在[cgroup][20] 容器中编排应用文档（如JAR，tarballs，ZIP文件）而开发的，是2014年最先支持Docker容器的编排工具之一。
|
||||
|
||||
所以当人们将Docker和Kubernetes与Mesos进行比较时，他们实际上是将Kubernetes和Docker Swarm与在Mesos上运行的Marathon进行了比较。
|
||||
|
||||
为什么搞清楚这一点很重要？ 因为Mesos坦率地讲并不在乎它上面运行了什么。 Mesos可以在共享的基础设施上弹性地为Java应用服务器提供集群服务，Docker容器编排，Jenkins 持续集成任务，Apache Spark分析，Apache Kafka 流，以及更多其他的服务。Mesoss甚至可以运行Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。
|
||||
|
||||
|
||||
|
||||
来源: Apache Mesos 调查 2016
|
||||
|
||||
Mesos的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos已经在大规模生产环境下（成千上万台服务器）运行了超过7年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。
|
||||
|
||||
### 我所说的这些什么意思？
|
||||
|
||||
总而言之，所有这三种技术都与Docker容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者加速你的微服务计划，Docker容器和开发工具就是最好的选择。
|
||||
|
||||
如果你们是一个dev / devops团队，并希望构建一个专门用于Docker容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如Google容器引擎或Azure容器服务），Kubernetes是一个可以考虑的好技术。
|
||||
|
||||
如果你们需要建立一个运行多个关键任务工作负载的可靠平台，包括Docker容器，旧的应用程序（例如Java）和分布式数据服务（例如Spark，Kafka，Cassandra，Elastic），并希望所有这些可依移植到云端提供商或者数据中心，那么Mesos（或我们自己的Mesos发行版，Mesosphere DC / OS）更适合你们的需求。
|
||||
|
||||
无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。 你的选择真的不会有错。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/?from=timeline&isappinstalled=0&nsukey=b2Ig6wj1rvlgVuEZ8ens0KVLuxYx7zv7GLuL1KBpcSWpvkfF2nHcSqeKJ7JnP%2FckIM4vBaRUkwdlUpWHNzrY8va0G14sN323y7T7OEix0DZpQOUQ%2FeiRcA7wJWN3Rws4PVSSI0wapm%2Bl5jCf%2B%2Bbj5HioS%2B%2FOeeil79KMIFrgFjKRMRWwZvlbOyq4j4iaipOi
|
||||
|
||||
作者：[Amr Abdelrazik ][a]
|
||||
译者：[rieonke](https://github.com/rieonke)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://mesosphere.com/blog/author/amr-abdelrazik/
|
||||
[1]:https://en.wikipedia.org/wiki/Cgroups
|
||||
[2]:https://docs.docker.com/engine/docker-overview/
|
||||
[3]:https://mesosphere.github.io/marathon/
|
||||
[4]:https://www.google.com/url?q=https://www.youtube.com/watch?v=sGWQ8WiGN8Y&feature=youtu.be&t=35m10s&sa=D&ust=1500923856666000&usg=AFQjCNFLtW96ZWnOUGFPX_XUuVOPdWrd_w
|
||||
[5]:https://www.nomadproject.io/
|
||||
[6]:http://kubernetes.io/
|
||||
[7]:https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/
|
||||
[8]:https://www.cncf.io/
|
||||
[9]:https://www.opencontainers.org/
|
||||
[10]:https://www.linuxfoundation.org/news-media/announcements/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-0
|
||||
[11]:https://research.google.com/pubs/pub43438.html
|
||||
[12]:https://www.youtube.com/watch?v=C_WuUgTqgOc
|
||||
[13]:https://youtu.be/F1-UEIG7u5g
|
||||
[14]:http://www.businessinsider.com/apple-siri-uses-apache-mesos-2015-8
|
||||
[15]:https://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html
|
||||
[16]:http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html
|
||||
[17]:https://medium.com/netflix-techblog/distributed-resource-scheduling-with-apache-mesos-32bd9eb4ca38
|
||||
[18]:https://martinfowler.com/bliki/BlueGreenDeployment.html
|
||||
[19]:https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/
|
||||
[20]:https://en.wikipedia.org/wiki/Cgroups
|
||||
[21]:https://mesosphere.com/blog/author/amr-abdelrazik/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user