为什么云计算实例会启动虚拟机而不是容器(解决办法)

解决方案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),它绝对不是“一个解决方案适合所有”的事情。不必运行整个内核并执行其他类型的虚拟化(图形、音频、网络等)确实会减少很多开销,但还必须考虑使用容器的缺点,其中一些我已经在我的回答中提到。

    推荐阅读