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

我试图很好地理解容器技术，但有点困惑。 似乎某些技术与堆栈的不同部分重叠，并且DevOps团队认为适合使用不同技术的不同部分（例如，可以使用Docker容器，但不必使用Docker引擎，可以使用来自云提供程序的引擎代替）。 我的困惑在于理解“容器堆栈”提供的每一层以及每个解决scheme的关键提供者是谁。

这是我的外行的理解; 我会理解的任何更正和反馈漏洞的理解

1. 容器：自包含的软件包，包括应用程序，运行时环境，系统库等。 像一个应用程序的迷你操作系统
   • Docker似乎是事实上的标准。 任何其他显着和广泛使用？
2. 容器群集：共享资源的容器组
3. 容器引擎：将容器分组成集群，pipe理资源
4. Orchestrator：这与容器引擎有什么不同？ 怎么样？
   • Docker Engine，rkt，Kubernetes，Google Container Engine，AWS Container Service等位于＃2-4之间？

Answer 1

@iamnat提供了一个非常好的简洁的解释。 让我试着从最基本的原则上稍微详细地解释一下。 这可能会有点长，并呈现一些简单化，但应该足以让这个想法。

物理机器

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

这个模型的缺点是：

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

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

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

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

虚拟机

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

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

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

• 它们在运行整个操作系统实例时消耗大量的资源。
• 他们可能不会像我们想要的那样快速地开始/下降（以秒为单位）。

• 即使使用硬件辅助虚拟化，应用程序实例也可能会在直接在主机上运行的应用程序中看到显着的性能下降 （这可能只是某些types的应用程序的问题）

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

集装箱

然后，在该行的某个地方， cgroups（控制组）被添加到了linux内核中。 此function让我们可以将组中的进程隔离起来，决定可以看到的其他进程和文件系统，并在组级别执行资源记帐。

各种各样的容器运行时和引擎出现了，这使得创build一个“容器”的过程，OS内部的一个环境，就像一个有限的可视性，资源等非常容易的名字空间。 这些常见的例子包括docker，rkt，runC，LXC等。

例如，Docker包含了一个守护进程，它提供了一些相互作用，比如创build一个“图像”，这个可重用的实体可以立刻被发送到容器中。 它也让我们以直观的方式pipe理单个容器。

容器的优点：

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

还有一些缺点：

• 提供的隔离级别比虚拟机的隔离级别要低。
• 他们最容易使用无状态的12因子应用程序重新构build，如果试图部署遗留应用程序，集群分布式数据库等等，则需要稍微努力。
• 他们需要协调和更高层次的原语来有效和规模地使用。

容器编排

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

• 容器之间的networking
• 负载均衡
• pipe理附加到这些容器的存储
• 更新容器，扩展容器，在多节点集群中的节点上传播它们等等。

当我们想要pipe理一个容器集群时，我们使用容器编排引擎。 这些例子包括Kubernetes，Mesos，Docker Swarm等。除了上面列出的function之外，它们还提供了大量的function，目标是减lessdev-ops的工作量。

---

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

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

Answer 2

具体回答你的问题：

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

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

3. Kubernetes：pipe理使用容器的分布式应用程序生命周期的工具集合。 包含用于pipe理容器，容器组，容器组态，容器configuration，编排容器，在实际实例中调度它们的工具，以及帮助开发人员编写和维护处理容器的其他服务/工具的工具。

4. Google容器引擎：与其获取虚拟机，在其上安装“docker-engine”，在其上安装kubernetes，并将其全部用于诸如对基础架构的正确权限之类的事情上。想象一下，如果它们合在一起，以便您可以select机器的types和你的集群的大小，所有这些只是工作。 像从项目特定的docker仓库（谷歌容器registry）拉图像或声称持久卷，或configuration负载平衡器只是工作，而不必担心服务帐户和权限，什么不是。

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

为了解决你的理解中的一些问题：你对事物的松散（除了我认为的容器引擎）。 理解唯一重要的东西是容器是什么是很重要的。 其余的只是营销/产品的名称。 了解现在对容器的理解已经被Docker容器所歪曲，以及Docker强制实施的许多意见和围绕Docker的工具也是很重要的。 集装箱已经存在很长时间了。

所以，一旦你了解Docker容器是什么，容器引擎只是一个pipe理它们的工具，容器集群只是一组容器，一个Orchestrator只是一个工具，用来pipe理容器根据一些参数运行的地方。 恕我直言，你真的不需要太担心什么其他的工具是一旦你了解和围绕容器build立一个坚实的心智模式。 其余的将自动适应。

理解这一切的最好方法是什么？ 使用Docker构build和部署一个体面复杂的应用程序（在应用程序中保存数据/使用数据库），一切都将有意义。