容器技术：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 Container Engine，AWS Container Service等在＃2-4之间？

Answer 1

这可能有点长，并且有些过于简单，但应该足以让我们了解这个想法。

物理机器

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

该模型的缺点是：

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

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

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

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

虚拟机

虚拟机解决了上述一些问题：

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

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

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

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

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

集装箱

然后，沿着这条线的某个地方， cgroups（控制组）被添加到linux内核中。 此功能允许我们隔离组中的进程，确定他们可以看到的其他进程和文件系统，并在组级别执行资源记帐。

各种容器运行时和引擎的出现使得创建“容器”的过程，操作系统中的环境，如具有有限可见性，资源等的命名空间，非常容易。 这些常见的例子包括docker，rkt，runC，LXC等。

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

容器的优点：

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

还有一些缺点：

• 提供的隔离级别小于VM的级别。
• 它们最容易使用重新构建的无状态12因子应用程序，如果尝试部署遗留应用程序，集群分布式数据库等，则会轻微挣扎。
• 它们需要编排和更高级别的原语才能有效且大规模地使用。

容器编排

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

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

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

---

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

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

Answer 2

要具体回答你的问题：

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

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

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

4. 谷歌容器引擎：不是获取虚拟机，而是在它们上面安装“docker-engine”，在它们上面安装kubernetes并将它们全部用于基础设施的正确权限之类的事情等等。想象一下如果这一切都汇集在一起​​以便你可以选择具有所有这些功能的机器类型和集群大小正常工作。 从项目特定的docker存储库（谷歌容器注册表）中提取图像或声明持久性卷或配置负载平衡器等工作只需要工作而不必担心服务帐户和权限。

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

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

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

理解这一切的最好方法是什么？ 使用Docker构建和部署一个相当复杂的应用程序（持久化数据/在您的应用程序中使用数据库），一切都会有意义。