容器技术：docker、rkt、orchestration、kubernetes、GKE和AWS容器服务

我试图对容器技术有一个很好的理解，但有点困惑。似乎某些技术重叠在堆栈的不同部分，不同技术的不同部分可以在DevOps团队认为合适的情况下使用（例如，可以使用Docker容器，但不必使用Docker引擎，可以使用云提供商的引擎）。我的困惑在于理解“容器堆栈”的每一层提供了什么，以及每个解决方案的关键提供者是谁

这是我外行的理解；如果您对我理解中的漏洞有任何更正和反馈，我将不胜感激

容器：自包含的包，包括应用程序、运行时环境、系统库等。；就像一个带应用程序的迷你操作系统

• 似乎Docker是事实上的标准。还有其他值得注意和广泛使用的吗

容器集群：共享资源的容器组

容器引擎：将容器分组到集群中，管理资源

编排器：这与容器引擎有什么不同吗？怎么用？

• Docker引擎、rkt、Kubernetes、Google容器引擎、AWS容器服务等在2-4之间的位置

---

具体回答您的问题：

Docker engine：管理Docker容器和Docker映像生命周期的工具。创建、重新启动、删除docker容器。创建、重命名、删除docker图像

rkt：类似于docker引擎，但实现不同

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

Google容器引擎：不是获取虚拟机，而是在虚拟机上安装“docker引擎”，在它们上安装kubernetes，并使其与基础设施的正确权限等一起工作。想象一下，如果所有这些都一起工作，那么您可以选择机器的类型和集群的大小，这些都可以正常工作。从特定于项目的docker存储库（google container registry）中提取图像、声明持久卷或配置负载平衡器等都可以正常工作，而不必担心服务帐户和权限等问题

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

解决您理解中的问题：您在某些事情上大致正确（我认为容器引擎除外）。重要的是要了解，唯一重要的是要了解容器是什么。剩下的只是营销/产品名称。同样重要的是要理解，今天对容器的理解被Docker容器是什么以及Docker和Docker周围的工具强制执行的许多观点所扭曲。集装箱已经存在很长时间了

因此，一旦您了解了（docker）容器是什么，容器引擎只是一个管理它们的工具，容器集群只是一组容器，编排器只是一个基于某些参数管理容器运行位置的工具。IMHO，一旦您了解并围绕容器构建了一个坚实的心智模型，您就不必太担心工具的其余部分是什么。其余的将自动适应

---

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

这可能有点长，而且过于简单，但应该足以让人理解这个想法

物理机器 不久前，部署简单应用程序的最佳方法是购买一个新的Web服务器，在其上安装您喜爱的操作系统，然后在那里运行您的应用程序

这种模式的缺点是：

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

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

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

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

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

• 即使在同一台机器上运行，它们也提供隔离
• 它们提供了一个标准的执行环境（来宾操作系统），与底层硬件无关
• 在缩放时（以分钟为单位），它们可以在不同的机器上快速启动（复制）
• 从物理硬件到虚拟机的移动通常不需要重新构建应用程序

但它们也带来了一些自身的问题：

• 它们在运行整个操作系统实例时会消耗大量资源
• 它们的启动/下降速度可能不如我们希望的快（秒数）
• 即使使用硬件辅助虚拟化，应用程序实例也可能会在运行虚拟化的应用程序上出现显著的性能下降