创建 Ec2 Container Engine 集群时，它会创建一个 Compute Engine 托管实例组来管理创建的实例。这些实例来自 Ec2 服务，也就是说，它们是虚拟机。
但我们知道容器代表了一种基于操作系统级虚拟化而不是硬件虚拟化来部署容器的新方法 像重量级且不可移植的虚拟机，这不是矛盾吗？如果我错了纠正我。
我们使用容器是因为与 VM 相比，它们的速度非常快（无论是在启动时间还是在任务执行方面），并且可以节省大量存储空间。因此，如果我们有一个最多可以支持 4 个容器的节点（vm），我们的客户可以快速午餐 4 个容器，但超过这个数量，Ec2 自动缩放器将需要午餐一个新的节点（虚拟机）来支持即将到来的容器，这会产生一些任务延迟。
难道不能在物理机上启动容器吗？
对于运行关键时间执行任务，您有什么建议？
【问题讨论】：
标签： amazon-web-services amazon-ec2 amazon-ecs
我相信您是在错误的假设下工作，即 ECS 会根据任务需求直接扩展虚拟机（“容器实例”——容器将运行的实例）。
如果这是真的，那么您就有道理了，因为在容器实例资源不足且无法立即可用的任何时候，集群都会变得迟缓且无响应。
ECS 不这样做，尽管 Auto Scaling 组存在。
根据您在集群中使用的 Amazon EC2 实例类型以及集群中容器实例的数量，您的任务在运行时可以使用的资源数量有限。 ECS 监控集群中可用的资源，以便与调度程序一起放置任务。 如果您的集群在任何这些资源（例如内存）上运行不足，您最终将无法启动更多任务，直到您添加更多容器实例、减少服务中所需任务的数量或停止集群中的一些正在运行的任务以释放受限资源。 （强调）
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch_alarm_autoscaling.html
所以，不...当您的容量不足时，它不会缓慢启动新任务。它根本不会启动它们。
但不要超过我。
上面的链接通过示例解释了虚拟机（容器实例）的扩展是如何设计为实际工作的。
当然，您根本不必让它们自适应地扩展。您可以使用您的物理服务器模型（注意：我说物理服务器 model - 意思是固定的、非弹性的资源池，在始终运行的虚拟机上，因为虚拟机是 EC2 提供的），并且只需选择您一直等待运行的实例数量，本质上是模拟物理服务器。例如，如果您想要 8 个容器实例，“自动缩放组”将始终保持 8 个，如果其中一个发生硬件故障，则会创建替换。这种“自动”成就将维持现状。当然，在这种配置中，您可以手动将 8 重新配置为 12，“自动”成就将自动获得 4 个新的添加到现有的 8。
但是，如何理想地使用该服务的想法是，您的虚拟机组可以根据您设计的规则进行扩展和缩减，以预测未来任务所需的资源 - 或未来缺乏的资源任务。
在给出的示例中，内存预留是触发器：
当您的集群的内存预留上升到 75% 以上时（意味着您的集群中只有 25% 的内存可供新任务预留），警报会触发 Auto Scaling 组添加另一个实例并提供更多为您的任务和服务提供资源。
它会触发添加更多容器实例，以便您始终拥有在您需要时已经在线的任何您确定的适当剩余容量阈值。
当然，内存只是一种资源，75% 只是为示例选择的任意阈值。
Auto Scaling Groups 可以根据各种触发器进行扩展 - 月亮的短语、股票市场的价格趋势、任何适合预测您想要的 剩余 容量的内容，并且可以可以使用quantified和monitored...但是当由于资源不足而无法启动任务时，该服务不会通过实际尝试启动新任务来直接扩展自身。
这就是你原来论点的缺陷。
为什么是虚拟机？很简单，因为当您因为预计不需要该容量而销毁虚拟机时，您就不再为此付费了。
从这个角度来看，也许你会同意这不是弱点，而是优势。当您不使用物理服务器时，它们永远不会停止花费您。
您根本不需要为虚拟机不需要的容量支付任何费用 - 您只需为正在使用的容量加上为处理预期需求而需要立即保留的容量付费。
您可以立即准备好尽可能多的闲置剩余，只要您愿意支付，或者您可以通过允许尽可能少的剩余容量来最大限度地节省资金，因为您可以毫不拖延地访问。
【讨论】：