例如，在 AWS 中，当我启动一个新的 EC2 实例时，它会加载一个新的 VM，然后用容器映像填充 VM。这就是为什么启动新的 EC2 实例需要 60-90 秒的原因。
出于好奇，让 AWS 按原样运行主机有什么缺点，当用户想要“启动 EC2 实例”时，AWS 只会启动具有受限权限的容器，并只允许用户访问该容器？
优点是计算实例会非常快速地启动。我还在学习云技术，所以我只是想知道缺点是什么。
也许不使用虚拟机就很难分配 CPU 资源？结果，用户会争相占用可用的 CPU？或者可能存在一些安全问题？我很想了解一下。
答案1
您的问题在某种程度上是倒着看问题：EC2 不是碰巧使用虚拟机的通用托管解决方案；它是一种托管虚拟机的服务。因此，有几种方法可以解释您的问题。
为什么 EC2 不被设计为使用容器？
这个问题的答案可以从时间线上推断出来：EC2 于 2006 年推出测试版，2008 年全面投入生产；Docker 直到 2013 年才公开发布，而 Kubernetes 则是在 2015 年。
EC2 发布时，容器技术正在开发中 - BSD 已经有了“jails”，而 Linux 也有一些形式的命名空间隔离- 但那时的生态系统还不是我们今天所熟悉的成熟生态系统。另一方面，虚拟专用服务器是一个成熟的概念 -VMWare 在 2002 年明确推销 ESX 用于托管服务， 这Xen 虚拟机管理程序2003 年，利诺德同年推出。EC2 的创新是启动虚拟服务器的系统一经请求使用这项成熟的技术。
为什么 EC2 还没有从虚拟机转移到容器？
虽然容器在某些方面可以被认为是“轻量级虚拟机”，但这并不是完整的描述，而且两者不可互换。虚拟机旨在让用户产生一种错觉，即他们正在访问物理服务器，完全控制整个系统；网络等资源以虚拟硬件的形式呈现，用户可以根据需要直接与其交互。容器呈现的抽象更有限，应用程序通常与容器本身的配置更紧密地绑定在一起，例如仅转发特定的网络端口。
多年来，亚马逊增加了许多服务，但在淘汰客户依赖的旧服务方面非常保守。因此，他们确实提供了许多基于容器而非虚拟机的服务，例如弹性云服务器（Elastic Container Service，2014 年推出），Fargate（2017 年推出），以及艾克斯（Elastic Kubernetes Service，于 2018 年推出）；但如果用户仍在使用 EC2，他们不太可能淘汰它。
为什么用户还没有转向容器服务？
既然基于容器的云托管已经可用，为什么人们仍然选择使用像 EC2 这样的基于 VM 的服务？
我认为有几个原因；我想到以下几个：
- 熟悉度：人们了解如何配置虚拟机，并且可以相对快速地了解本地虚拟机和 EC2 实例之间的差异。了解容器技术需要更多的再培训。
- 迁移成本：现有系统通常无需修改即可在 EC2 实例上运行，包括整个操作系统和图形界面。容器化应用程序通常更为复杂。
- 安全性：系统共享的部分越少，数据泄露给其他客户的风险就越低。容器托管服务通常会尝试通过为每个客户编排单独的虚拟机来缓解这种情况，但这会对您提到的某些指标（如启动速度）产生明显的成本。
因此，尽管容器越来越受欢迎，但它们尚未完全取代虚拟服务器，而且可能永远不会。因此，EC2 和类似的基于 VM 的云托管服务将继续存在。
答案2
容器通常只运行单个应用程序，并且是不可变的，即重启后更改不会保留。容器也没有自己的内核。
另一方面，虚拟机运行整个操作系统，包括内核、初始化脚本、系统守护进程等。并且存储通常在重启后保留。
虚拟机和容器有不同的用途 - 在谷歌上搜索“虚拟机与容器”，互联网上有很多相关信息。
如果你想跑AWS 中的容器即服务无需担心底层虚拟机AWS Fargate- 这正是您想要的。
希望有帮助:)
答案3
安全肯定是一个原因。容器与主机共享同一个内核。因此它们不被视为 100% 隔离。
但云提供商也提供容器。AWS 也提供容器。我猜容器比虚拟机便宜，但我还没有查过。
本质上，你问的是一个更普遍的话题，虚拟机与容器；无论平台如何，都有相同的优点和缺点。
答案4
容器有几种不同的方法，目前公认的答案似乎只适用于 OCI 风格（类似 docker）的容器。还有许多其他类型的容器，例如 LXC 和 BSD jail，它们有不同的方法。
例如，LXC 可以轻松容纳多个应用程序，并且默认情况下是可变的。它还具有 init 脚本和系统守护程序（systemd 等）。
也许不使用虚拟机就更难分配 CPU 资源？结果，用户会争相占用可用的 CPU？
使用容器可以轻松分配 CPU、RAM 和磁盘空间资源。
好处是计算实例会快速启动。
配置容器不是一项即时任务（但可以比“60-90 秒”更快），因为您仍然需要获取图像、提取它并启动它。
或者可能存在一些安全问题？
安全是我提到的所有容器解决方案的主要问题，因为它们都共享一个内核。虽然已经采取了许多安全措施，但偶尔还是会发现漏洞。如果你和朋友共享一个服务器，并且你们都在其中安装了容器，那么你们可能基本是安全的，但在亚马逊这样的大型提供商（有大量企业使用他们的服务）的规模下，这可能是一个重大的安全隐患。
如果你检查AWS Fargate 网站例如，它指出其容器的许多资源不共享，从这个方面来看，它比传统的自托管容器更接近虚拟机：
各个 ECS 任务或 EKS Pod 各自在自己的专用内核运行时环境中运行，并且不与其他任务和 Pod 共享 CPU、内存、存储或网络资源。这可确保每个任务或 Pod 的工作负载隔离和更高的安全性。
我要指出的最后一个问题是兼容性。由于您对内核（以及可能的系统调用）的访问受到限制，因此您无法执行某些任务，例如加载 dkms 模块或执行 sysctl 配置。并非所有应用程序都会在此运行，但这些往往是例外，而不是常态。
容器有许多有效的用例（包括 OCI 类和 LXC 类），而且它绝对不是“一刀切”的解决方案。无需运行整个内核并执行其他类型的虚拟化（图形、音频、网络等）确实可以减少很多开销，但也必须考虑使用容器的缺点，其中一些我在我的回答中提到过。