解决方案1：
云计算实例启动虚拟机解决办法：容器通常只运行一个应用程序并且是不可变的，即在重新启动时不会保留更改。容器也没有自己的内核。
另一方面，VM运行整个操作系统，包括内核、初始化脚本、系统守护进程等。并且存储通常在重新启动时保留。
虚拟机和容器有不同的用途 - 谷歌搜索“虚拟机与容器”之类的东西，互联网上有很多。
如果你想在 AWS 中将容器作为服务运行而不必担心底层 VM，请查看AWS Fargate - 这正是你想要的。
希望有帮助:)
解决方案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 的云托管服务将继续存在。
解决方案3：
安全绝对是一个原因。容器在它们和主机之间共享相同的内核。所以他们不被认为是 100% 孤立的。
然而，云提供商也提供容器。AWS 也这样做。我认为容器比虚拟机便宜，但我没有检查过。
从本质上讲，你问的是一个更笼统的话题，VM 与容器；无论平台如何，都适用相同的优点和缺点。
解决方案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），它绝对不是“一个解决方案适合所有”的事情。不必运行整个内核并执行其他类型的虚拟化（图形、音频、网络等）确实会减少很多开销，但还必须考虑使用容器的缺点，其中一些我已经在我的回答中提到。
