21

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

这是我外行的理解；希望对我的理解中的漏洞进行任何更正和反馈

  1. Containers：自包含的包，包括应用程序、运行时环境、系统库等；就像一个带有应用程序的迷你操作系统
    • 看起来 Docker 是事实上的标准。还有其他值得注意且广泛使用的吗？
  2. 容器集群：共享资源的容器组
  3. Container Engine：将容器分组，管理资源
  4. Orchestrator：这与容器引擎有什么不同吗？如何？
    • Docker Engine、rkt、Kubernetes、Google Container Engine、AWS Container Service 等在#s 2-4 之间处于什么位置？
4

2 回答 2

31

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

物理机器

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

传统模式

该模型的缺点是：

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

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

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

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

虚拟机

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

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

虚拟机

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

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

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

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

容器

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

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

容器

码头工人/rkt/...

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

容器的优点：

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

也有一些缺点：

  • 提供的隔离级别低于虚拟机的情况。
  • 它们最容易与重新构建的无状态12 因子应用程序一起使用，如果尝试部署遗留应用程序、集群分布式数据库等，则会遇到一点困难。
  • 他们需要编排和更高级别的原语才能有效和大规模地使用。

容器编排

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

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

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

编排

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

ECS 是由 Amazon 构建和运营的专有容器管理/编排系统，可作为 AWS 套件的一部分使用。

于 2016-10-22T08:25:05.717 回答
8

具体回答您的问题：

  1. Docker 引擎：管理 docker 容器和 docker 镜像生命周期的工具。创建、重启、删除 docker 容器。创建、重命名、删除 docker 镜像。

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

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

  4. Google Container Engine：与其获取虚拟机，不如在其上安装“docker-engine”，在其上安装 kubernetes 并使其与基础设施的正确权限等事情一起工作。想象一下，如果所有这些都结合在一起，以便您可以选择机器的类型和集群的大小让所有这些都正常工作。诸如从项目特定的 docker 存储库（谷歌容器注册表）中提取图像或声明持久卷或配置负载均衡器之类的事情都可以正常工作，而无需担心服务帐户和权限等等。

  5. ECS：类似于 GKE (4)，但没有 Kubernetes。

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

因此，一旦您了解了（docker）容器是什么，容器引擎只是管理它们的工具，容器集群只是一组容器，编排器只是根据某些参数管理容器运行位置的工具。恕我直言，一旦您了解并围绕容器构建了可靠的思维模型，您真的不需要太担心其余的工具是什么。其余的将自动适应。

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

于 2016-10-20T21:48:30.087 回答