容器技术：docker，rkt，orchestration，kubernetes，GKE和AWS Container Service

Question

我正在努力了解容器技术，但有些困惑。看起来某些技术会重叠堆栈的不同部分，并且可以使用不同技术的不同部分，因为DevOps团队认为合适（例如，可以使用Docker容器但不必使用Docker引擎，可以使用来自云提供商的引擎）代替）。我的困惑在于理解“容器堆栈”的每一层提供的内容以及每个解决方案的关键提供者是谁。

这是我的外行人的理解;非常感谢我理解中对漏洞的任何更正和反馈

1. 容器：包含应用程序，运行时环境，系统库等的自包含程序包;就像带有应用程序的迷你操作系统一样
   • 似乎Docker是事实上的标准。还有其他值得注意和广泛使用的其他产品吗？
2. Container Clusters：共享资源的容器组
3. 容器引擎：将容器分组到群集中，管理资源
4. Orchestrator：这与容器引擎有什么不同？怎么样？
   • Docker Engine，rkt，Kubernetes，Google容器引擎，AWS容器服务等在＃2-4之间落在哪里？

Answer 1

这可能有点长，并且过于简单化，但应该足以让这个想法得以实现。

物理机

前一段时间，部署简单应用程序的最佳方法是简单地购买新的Web服务器，在其上安装您喜欢的操作系统，然后在那里运行您的应用程序。

这个模型的缺点是：

• 进程可能会相互干扰（因为它们共享CPU和文件系统资源），并且可能会影响其他进程的性能。

• 向上/向下扩展此系统也很困难，需要花费大量精力和时间来设置新的物理机器。

• 物理机的硬件规格，操作系统/内核版本和软件包版本可能存在差异，这使得难以以硬件无关的方式管理这些应用程序实例。

直接受物理机规格影响的应用程序可能需要特定的调整，重新编译等，这意味着集群管理员需要将它们视为单个机器级别的实例。因此，这种方法不能扩展。这些属性使其不适合部署现代生产应用程序。

虚拟机

虚拟机解决了上述问题：

• 即使在同一台机器上运行，它们也能提供隔离。
• 它们提供标准执行环境（客户操作系统），而不管底层硬件如何。
• 缩放时（分钟的顺序），它们可以很快地在不同的机器上进行（复制）。
• 通常不需要重新设计应用程序以从物理硬件迁移到虚拟机。

但是他们引入了一些自己的问题：

• 在运行整个操作系统实例时，它们会消耗大量资源。
• 他们可能无法按照我们想要的速度开始/下降（秒数）。

• 即使使用硬件辅助虚拟化，应用程序实例也可能会在直接在主机上运行的应用程序中显着降低性能。 （这可能仅适用于某些类型的应用程序）

• 打包和分发VM映像并不是那么简单。 （这不是该方法的缺点，因为它是现有的虚拟化工具。）

容器

然后，在该行的某处，cgroups (control groups)被添加到linux内核中。此功能允许我们隔离组中的进程，确定他们可以看到的其他进程和文件系统，并在组级别执行资源记帐。

各种容器运行时和引擎的出现使得创建一个容器＆＃34;这个OS中的环境的过程，如一个具有有限可见性，资源等的命名空间，非常容易。这些常见的例子包括docker，rkt，runC，LXC等。

例如，Docker包含一个守护进程，它提供了诸如创建＆＃34; image＆＃34;之类的交互，这是一个可以立即启动到容器中的可重用实体。它还允许以直观的方式管理单个容器。

容器的优点：

• 它们重量轻，运行时开销很小，因为它们没有自己的内核/操作系统实例，并且运行在单个主机操作系统之上。
• 它们在各种容器之间提供了一定程度的隔离，并且能够对它们消耗的各种资源施加限制（使用cgroup机制）。
• 围绕它们的工具已经迅速发展，可以轻松构建可重复使用的单元（图像），存储图像修订的存储库（容器注册表）等，主要是由于码头工具。
• 鼓励单个容器运行单个应用程序进程，以便独立维护和分发它。容器的轻质特性使其更加优选，并且由于去耦而导致更快的发展。

还有一些缺点：

• 提供的隔离级别低于虚拟机的隔离级别。
• 最简单的方法是重新构建无状态12-factor应用程序，如果尝试部署遗留应用程序，群集分布式数据库等，则会轻微挣扎。
• 他们需要编排和更高级别的原语才能有效且大规模地使用。

Container Orchestration

在生产中运行应用程序时，随着复杂性的增加，它往往会有许多不同的组件，其中一些组件会根据需要进行扩展/缩小，或者可能需要进行扩展。容器本身并不能解决我们所有的问题。我们需要一个能够解决与真实大规模应用相关的问题的系统，例如：

• 容器之间的联网
• 负载平衡
• 管理附加到这些容器的存储
• 更新容器，扩展容器，将它们分布在多节点集群中的节点上等等。

当我们想要管理容器集群时，我们使用容器编排引擎。这些例子包括Kubernetes，Mesos，Docker Swarm等。除了上面列出的功能外，它们还提供了许多功能，目标是减少开发人员的工作量。

GKE（Google容器引擎）在Google Cloud Platform上托管了Kubernetes。它允许用户简单地指定他们需要一个n节点kubernetes集群，并将集群本身公开为托管实例。 Kubernetes is open source如果有人愿意，也可以在Google Compute Engine，不同的云提供商或他们自己的数据中心内的机器上进行设置。

ECS是由亚马逊构建和运营的专有容器管理/编排系统，可作为AWS套件的一部分提供。

Answer 2

具体回答您的问题：

1. Docker引擎：一种管理docker容器和docker镜像生命周期的工具。创建，重新启动，删除docker容器。创建，重命名，删除泊坞窗图像。

2. rkt：类似于docker引擎，但实现方式不同

3. Kubernetes：用于管理使用容器的分布式应用程序生命周期的工具集合。包含管理容器，容器组，容器配置，在实际实例上安排它们的工具，帮助开发人员编写和维护其他服务/工具来处理容器的工具。

4. Google容器引擎：安装＆＃34; docker-engine＆＃34;而不是获取虚拟机在他们身上，在他们身上安装kubernetes并使用所有权利来处理诸如基础设施的正确权限之类的事情等等。想象一下，如果这一切都汇集在一起​​，那么你可以选择机器的类型和拥有所有这些的集群的大小刚刚工作。诸如从项目特定的docker存储库（google容器注册表）中提取图像或声明持久卷或配置负载平衡器之类的工作只需要工作而不必担心服务帐户和权限以及什么不是。

5. ECS：类似于GKE（4），但没有Kubernetes。

为了解决你的理解中的要点：你对事物的看法是正确的（我认为容器引擎除外）。了解唯一重要的事情是容器是什么，这一点很重要。其余部分只是营销/产品名称。同样重要的是要理解今天对容器的理解是由Docker容器以及Docker和Docker工具强制执行的许多意见所扭曲的。容器已存在很长时间了。

因此，一旦你理解了（docker）容器是什么，容器引擎只是一个管理它们的工具，容器集群只是一组容器，一个orchestrator只是一个管理容器运行的工具的工具。一些参数。恕我直言，你真的不需要担心一旦你理解了其他工具，并围绕容器建立一个坚实的心理模型。其余的将自动适应。

了解所有这些的最佳方法是什么？建设与发展使用Docker部署一个相当复杂的应用程序（持久化数据/在您的应用程序中使用数据库），一切都会有意义。