Docker vs. Kubernetes:这不是一个或另一个的问题

在现代软件中，很少有名字能像Docker和Kubernetes那样炙手可热。

取码头工人首先，平台本质上已经成为容器技术的代名词。现在，你可能经常听到开发人员说“Docker”，而实际上他们指的是一般的容器;同一个开发人员很可能认为Docker是选择的容器平台。

Kubernetes与此同时，它被称为开源历史上速度最高的项目之一更仔细地观察就会发现．首先作为谷歌的内部工具开发Borg， Kubernetes后来被剥离出来作为容器编排的开源工具。

早期的采用者在他们的学习曲线中有一个重要的开端，但是许多软件专业人员和组织现在才开始了解容器、容器编排和相关趋势。在这篇文章中，我们将解释Docker和Kubernetes的内容和原因。我们将深入研究这些工具的一些最大趋势和用例，并涵盖基本问题，包括基本问题，如，我必须选择一个或另一个吗?(剧透警告:不，你不需要。我们会告诉你为什么。)

让我们跳!

码头工人和容器

根据码头工人的定义，容器映像“是一个轻量级的、独立的、可执行的软件包，包含了运行它所需的一切:代码、运行时、系统工具、系统库、设置。”

换句话说，容器封装了应用程序需要的所有东西——不仅是代码，还有它的所有依赖项、库和配置——并将它从运行它的任何环境(物理的或虚拟的)中抽象出来。理想情况下，这意味着您的代码在各种环境中一致地运行——从开发到测试到生产，从本地机器到云实例——而不需要重新调整工具。有些人将其称为操作系统级虚拟化，尽管“容器”是更常见、更流行的术语。

Docker在容器平台中家喻户晓的一个关键原因是，它是第一个将高级Linux内核特性打包在一起的容器，这种方式允许软件团队更容易地创建可打包的工件，它们可以在不同的服务器上运行。

Docker容器使开发人员更容易享受本地、测试、登台和生产环境之间的平等。从本质上说，开发人员现在可以在所有这些环境中运行相同的工件或Docker容器映像，从他们的笔记本电脑到生产环境以及两者之间的一切。

这使得开发工作流程和部署更加简化;而不是构建一个完整的服务器来运行一个服务或应用程序，你可以在一个主机上运行一个Docker容器映像，并使用该主机的少量资源来运行该服务或应用程序，甚至跨多个环境。

特别是与传统虚拟机映像相比，容器是“轻量级”且短暂的，这意味着它们将随着资源的增加或减少或应用需要扩展而上下旋转。

在DevOps、云架构和越来越多的分布式计算环境的时代，容器化具有巨大的优势，所有这些都导致了Docker的快速和广泛采用。

Kubernetes和容器编排

当然，容器化的工作流可能很复杂。docker的早期采用者(其中包括new Relic)发现，他们很快就在容器中运行了数百甚至数千个工作负载。这很快就成为一项操作挑战;可伸缩性不是免费的。

如果您有10个容器和4个应用程序，那么容器编排就不是什么大问题。如果有1000个集装箱和400个服务，情况就复杂得多了。继续增加这些数字，复杂性就会随之而来。

接下来是Kubernetes和容器编排。Kubernetes是一个用于自动化容器化应用程序的部署、管理和扩展的工具。自动化是关键;这也是为什么Kubernetes越来越成为用于现场可靠性工程师的工具以及其他基础设施和运营专家。Kubernetes使正在进行的数千个潜在容器的编配变得易于管理;它有助于确保您的服务始终在运行。

在早期，组织转向一些开源工具之一，包括Kubernetes，或者构建自己的工具来大规模管理容器。然而，Kubernetes在编配上的地位就像Docker在容器上的地位一样:实际上是同义词。

所以，Docker和Kubernetes是不一个非此即彼的选择;相反，将Docker和Kubernetes视为更大系统的两个重要部分可能会有所帮助。事实上,最近由The New Stack进行的一项调查发现Kubernetes的采用往往与容器的采用密切相关，后者推动了前者。(我们将在接下来的市场概述中深入探讨这一点。)

Kubernetes vs. Docker Swarm

如果有一种误解，认为Docker和Kubernetes是竞争对手，或者是非此即彼的命题，这并不是完全没有道理的。这在很大程度上是因为Docker生态系统包括自己的容器编排解决方案，码头工人群这是Kubernetes的替代品。

无论容器编排中是否有一个明确的“赢家”，Kubernetes都将成为2018年最接近的对象。的证据吗?Docker增加了对Kubernetes的强大支持今年早些时候他们揭幕的时候Docker企业版2.0，允许用户在同一个集群上同时运行Kubernetes和Docker Swarm。

在某些非生产用例中，例如仅在测试或开发环境中使用容器，使用Docker而不使用Kubernetes可能是非常好的。Docker Swarm以易于使用而闻名而对于大多数用户来说，Kubernetes的学习曲线通常更陡峭。

但是，一旦组织将大型的容器化工作负载转移到生产中，他们通常会发现Kubernetes是最好的选择(稍后您将看到一些相关的数据)。现在Docker使得企业更容易使用Kubernetes，这种配对几乎肯定会变得更加流行。

集装箱市场概述

让我们换一种方式，用美元来量化集装箱的价值。研究预测应用容器市场将接近2020年27亿美元而在2018年，这一数字预计为15亿美元。考虑到Docker只有5年的历史，而Kubernetes 1.0是在2015年7月发布的，这已经不错了。

关于集装箱市场份额的确切数据很难获得，因为集装箱市场还处于相对早期的阶段。但我们掌握的数据都表明了同样的事情:采用率正在增长，而且增长迅速。

451个研究的季度企业调查的声音例如，最近发现23.7%的受访者已经在使用集装箱。在最近的New Relic调查中，我们发现这一趋势在公共云用户中更加明显，26%的用户使用容器，39%的用户使用容器编配。451研究还指出，越来越多的企业在生产环境中运行容器，这表明我们可能正处于一个临界点，越来越多的公司将把容器的使用从开发和测试环境扩展到生产环境。

作为Docker庆祝了它的五岁生日2018年3月，该公司表示，集装箱下载量超过370亿次，Dockerized应用程序达到350万个，企业版客户超过450个。

Kubernetes的应用也在增长。New Stack的电子书，库伯内特生态系统的状况，获取了许多容器采用者的经验，注意到许多组织直到开始将容器部署到生产环境中才意识到编排是多么重要。

该网站分享的调查数据强调了这种关系:60%的组织报告在生产中广泛使用集装箱，也报告了广泛使用Kubernetes，另有19%的组织表示，他们已经开始在生产中使用Kubernetes。同样，58%的公司也表示在生产中使用Kubernetes。另有22%的受访者对Kubernetes进行了评估。

最新趋势:Docker和容器

那么，是什么推动了集装箱的需求呢?有一些重要且经常交叉的用例，在这些用例中，容器非常有意义:

• 多重云环境:您可能会越来越多地听到“多云”这个术语，它的意思和听起来一样:使用来自多个供应商的多个云服务。当涉及到为多个公共云环境构建应用程序时，容器(和编排)允许采用“一次构建”的方法。容器的可移植性在多云环境中也具有相当大的吸引力。
• 云迁移和应用程序现代化:虽然许多组织正在构建“云原生”应用程序，并且越来越多地将它们封装起来，但许多组织仍在运行传统应用程序。虽然有多种方法可以使旧的应用程序现代化，通常是为了将它们迁移到云环境更新遗留应用程序是容器使用的另一个潜在驱动因素。德勤咨询(Deloitte Consulting)首席云策略官David Linthicum分析了使用容器进行传统应用现代化的潜在好处从容器到微服务:更新遗留应用程序．
• Microservices:随着微服务体系结构(本质上是将应用程序分解为许多更小的独立服务)变得越来越流行，许多公司发现容器和编排为打包、部署和维护这些微服务制定了一种逻辑策略，特别是在规模上。
• 日益增长的社区:和Kubernetes一样，Docker也是开源的。几乎不可避免的是，Docker社区将继续与整体采用同步增长。码头工人中心例如，Docker允许用户公开存储和共享Docker图像供其他人使用，对于希望加快学习和采用Docker的新用户来说，这是一个潜在的丰富资源。

最新趋势:Kubernetes和配器

事实上，Kubernetes采用的最重要的原因可能是容器的采用。如上所述，许多组织发现大量的容器使用，特别是在生产环境中，需要健壮的编配。

Kubernetes的增长还有其他几个关键趋势。

• 支持Kubernetes的主要平台:Docker已经开始支持Kubernetes企业版这是一件大事。但这表明该行业得到了广泛支持，包括来自大公司的支持。最近的例子是Amazon Web Services (AWS)。迄今为止最大的公共云平台AWS刚刚推出Kubernetes的Amazon弹性容器服务，简称为Amazon EKS。Amazon EKS允许用户在AWS上使用Kubernetes运行容器化的应用，而无需安装或管理自己的Kubernetes集群。
• Kubernetes是一个很好的职业选择:站点可靠性工程师和其他运营专业人士正在意识到增加容器和编排专业知识——尤其是Kubernetes的专业知识——是一个明智的职业选择。另一方面，精明的企业意识到Kubernetes的使用有助于吸引尖端人才。码头工人吹嘘LinkedIn上有超过1.5万个与docker相关的招聘信息。
• 新兴服务网格:Kubernetes并不是万能的微服务和容器。重要的是，Kubernetes和容器从路由、安全性或发现的角度来看，在服务到服务的通信方面没有什么可说的，也没有什么可做的。新兴的开源项目，比如Istio(该公司拥有Lyft、IBM和谷歌等主要支持者)通过以一种语言无关的方式将服务对服务的通信功能集成到网络中，从而处理许多服务对服务的通信功能。网格允许开发人员专注于业务逻辑，而不必担心应用程序本身在哪里运行。与编制层集成的服务网格提供了特定于网络的特性，如安全策略或路由。

使用New Relic监控容器

作为Docker的早期采用者，New Relic敏锐地意识到健壮的需求，系统各层的有效监控:容器内部的应用程序或服务、容器本身和编制层。从操作的角度来看，我们特别关心提供能够看到整个画面的能力，而不仅仅是一个层。全栈可见性至关重要;毕竟，部署容器意味着又多了一件要监视的事情。

对于软件工程师来说，使用New Relic监控容器化的应用程序和编排可以提供关于代码执行情况的反馈。当问题发生时，他们可以更好地理解是代码、容器还是编制层中的问题。

我们一直在努力确保，随着Docker和Kubernetes生态系统中出现新的功能和平台，我们正在交付软件团队需要的监控功能，以实现他们的潜力我们的Amazon EKS集成．

的确，这些都是令人兴奋的、不断发展的技术。Docker和Kubernetes还很年轻。许多公司和DevOps团队的潜力还只是皮毛，还有很多东西需要探索。