所以我一直在试图弄清楚容器及其在基于云的服务中的使用（AWS Azure等），我真的没有看到为什么要使用它们。您可以在虚拟机上部署应用程序（或服务），也可以在容器中执行相同操作，但它仍然只能在某些环境Nx 1:1 VM to container中运行。
我想到的第二种方法是你有一个强大的虚拟机，最重要的是你有容器管理器将计算能力分配给容器VM 1:N containers - 但是运行的容器有什么不同。 VM没有容器？ Woulden的容器管理只会通过不必要的开销窃取您的计算能力？除此之外，通常价格是线性缩放（例如单个单位的价格与计数保持相同），因此有2台机器与一台机器有两个容器并且性能翻倍相同。
如果您能提供一些真正有用的云服务示例。
答案 0 :(得分：0)
容器就是要从硬件中获得更多密度 - 也就是说，考虑到你拥有的资源量，能够更有效地运行服务（因此节省了一些资金）。
主体是基于容器与VM不同，它们没有自己的操作系统副本等等这一事实，它们是一个更加简洁的沙箱，并由容器化技术管理top，控制容器可以访问的资源。
这也有助于更有效地扩展和更有效地分发（弹性），因为如果您将系统设计为一个容器运行一种类型的服务，容器管理层可以协调每个容器的实例数量。服务可以在任何时间旋转或分发。将此与SOA架构进行比较，这些架构通常（并非总是）按层而不是服务进行扩展 - 即。您的Web层将是一组运行Web服务器和服务的VM，运行多个后端服务的应用层等等。对于容器，您不需要进行区分，并且您可能拥有100个可独立扩展的层。
完美适应云，只需支付您所使用的内容 - 应用程序套件越精细，运行效率越高，因此您需要消耗的资源就越少。
然后，容器管理技术还可以管理弹性，网络，工作负载分配，规模等......
对于较小的应用程序或工作负载，您通常可以在一个或两个虚拟机上托管（或者如果您希望自动扩展，可以使用云服务或虚拟机规模集），使用容器可能会花费更多 - 通常您需要最少的托管容器的3 Vms通过硬件分配提供弹性，其中一些资源将由容器管理使用。因此，更合适的用例是具有许多不同服务组件的更大系统，每个服务组件可能随着时间的推移而变化。
根据技术的不同，通常实际VMS的数量可能会扩展，例如3到20之间，但每个节点通常会有多个容器 - 例如。每个虚拟机上有20个，因此使用3个VMS，您可以在扩展虚拟机之前托管3 x 20 = 60个服务实例。您不必预先确定60这些服务的类型。因此，您可以从3个仅托管3个服务的VM开始 - 可能是Web前端，计算服务和数据访问服务。随着需求的增长，最终可能会有10个前端服务实例，35个计算实例和5个数据访问层 - 使用10 + 35 + 5 = 50个60个容器。
这里有一个很好的视觉图片来描述容器的密度： Linux Journal