为什么云计算实例会启动虚拟机而不是容器？

Question

例如，在 AWS 中，当我启动一个新的 EC2 实例时，它会加载一个新的 VM，然后使用容器映像填充 VM。这就是启动新 EC2 实例需要 60-90 秒才能启动的原因。

出于好奇，让 AWS 按原样运行主机有什么缺点，当用户想要“启动 EC2 实例”时，AWS 只会启动一个具有受限权限的容器，并且只允许用户访问那个容器？

好处是计算实例会很快启动。我仍在学习云技术，所以我只是想知道缺点是什么。

也许在不使用 VM 的情况下分配 CPU 资源会更困难？结果，用户会互相争夺可用的CPU吗？或者也许有一些安全问题？很想了解这个。

Answer 1

容器通常只运行一个应用程序并且是不可变的，即在重新启动时不会保留更改。容器也没有自己的内核。

另一方面，VM 运行整个操作系统，包括内核、初始化脚本、系统守护进程等。并且存储通常在重新启动时保留。

虚拟机和容器有不同的用途 - 谷歌搜索“虚拟机与容器”之类的东西，互联网上有很多。

如果您想在 AWS 中将容器作为服务运行而不必担心底层 VM，请查看AWS Fargate - 这正是您想要的。

希望有帮助:)

Answer 2

在某种程度上，您的问题是向后看问题：EC2 不是碰巧使用 VM 的通用托管解决方案；它是一种用于托管 VM 的服务。因此，有几种方法可以解释您的问题。

为什么 EC2 没有设计为使用容器？

这个问题的答案可以从时间线中推导出来：EC2 于 2006 年推出测试版，并于 2008 年全面生产；Docker 直到 2013 年才公开发布，而 Kubernetes 是 2015 年。

容器技术在 EC2 推出时正在开发——BSD 已经有“监狱”，Linux 有某种形式的命名空间隔离——但这并不是我们今天熟悉的成熟生态系统。另一方面，虚拟专用服务器是一个成熟的概念——VMWare 在 2002 年明确销售 ESX 用于托管服务，Xen 管理程序在 2003 年紧随其后，Linode于同年推出。EC2 的创新是使用这种成熟技术按需启动虚拟服务器的系统。

为什么 EC2 没有从虚拟机迁移到容器？

尽管在某些方面可以将容器视为“轻量级 VM”，但这并不是完整的描述，并且两者不可互换。虚拟机旨在让用户错觉他们正在访问物理服务器，并完全控制整个系统；诸如网络之类的资源以虚拟硬件的形式呈现，用户可以根据需要直接与之交互。容器提供了更有限的抽象，应用程序通常与容器本身的配置更紧密地绑定在一起，例如只转发特定的网络端口。

多年来，亚马逊增加了许多服务，但对于淘汰客户依赖的旧服务非常保守。因此，他们确实提供了许多基于容器而非 VM 的服务，例如ECS（弹性容器服务，2014 年推出）、Fargate（2017 年推出）和EKS（弹性 Kubernetes 服务，2018 年推出）；但如果用户仍在使用 EC2，他们就不太可能淘汰它。

为什么用户还没有转向容器服务？

鉴于基于容器的云托管可用，为什么人们仍然选择使用 EC2 等基于 VM 的服务？

我认为有几个原因；想到的几个：

• 熟悉程度：了解如何配置虚拟机，可以较快地了解本地虚拟机和EC2实例的区别。了解容器技术需要更多的重新培训。
• 迁移成本：现有系统通常可以不加修改地在 EC2 实例上运行，包括整个操作系统和图形界面。容器化应用程序通常更复杂。
• 安全性：系统共享的越少，数据泄露给其他客户的风险就越低。容器托管服务通常会尝试通过为每个客户编排单独的 VM 来缓解这种情况，但这对于您提到的某些指标（例如启动速度）而言显然会产生成本。

因此，尽管容器越来越受欢迎，但它们还没有完全取代虚拟服务器，而且可能永远不会。因此，EC2 和类似的基于 VM 的云托管服务将继续存在。

Answer 3

安全绝对是一个原因。容器在它们和主机之间共享相同的内核。所以他们不被认为是 100% 孤立的。

然而，云提供商也提供容器。AWS 也这样做。我认为容器比虚拟机便宜，但我没有检查过。

从本质上讲，您问的是一个更笼统的话题，VM 与容器；无论平台如何，都适用相同的优点和缺点。

Answer 4

容器有几种不同的方法，当前接受的答案似乎只考虑了 OCI 风格（类似 docker）的容器。还有许多其他类型的容器，例如 LXC 和 BSD jail，它们有不同的方法。

例如，LXC 可以轻松包含多个应用程序，并且默认情况下是可变的。它还具有初始化脚本和系统守护进程（systemd 等）。

也许在不使用 VM 的情况下分配 CPU 资源会更困难？结果，用户会互相争夺可用的CPU吗？

使用容器可以轻松分配 CPU、RAM 和磁盘空间资源。

好处是计算实例会很快启动。

配置容器不是一项即时任务（但可以比“60-90 秒”更快），因为您仍然需要获取映像、提取它并启动它。

或者也许有一些安全问题？

安全性是我提到的所有容器解决方案的主要关注点，因为它们都共享一个内核。虽然有许多安全措施到位，但仍然偶尔会发现漏洞。如果你和你的朋友有一个共享的服务器，而且你们都有容器，你可能大部分都是安全的，但是在像亚马逊这样的大型供应商（有大量的企业使用他们的服务）的规模上，这可能很重要安全问题。

例如，如果您查看AWS Fargate 网站，它会指出其容器的许多资源未共享，从这方面来看，它比传统的自托管容器更接近 VM：

单个 ECS 任务或 EKS Pod 均在其自己的专用内核运行时环境中运行，并且不与其他任务和 Pod 共享 CPU、内存、存储或网络资源。这确保了每个任务或 Pod 的工作负载隔离和更高的安全性。

我要注意的最后一个问题是兼容性。由于您对内核（也可能是您的系统调用）的访问受到限制，因此您无法执行某些任务，例如加载 dkms 模块或执行 sysctl 配置。并非所有应用程序都会在此运行，但那些往往是例外而不是常态。

容器有许多有效的用例（类似 OCI 和类似 LXC），它绝对不是“一个解决方案适合所有”的事情。不必运行整个内核并执行其他类型的虚拟化（图形、音频、网络等）确实会减少很多开销，但也必须考虑使用容器的缺点，其中一些我已经在我的回答中提到。