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