我们正在尝试使用策略部署我们的应用程序＆＃34;每个主机一个任务＆＃34;因为我们使用主机网络而不是Docker＆＃39;之一。
我们从1个任务〜1个主机开始，随着（让我们说）CPU上升，我们看到当新任务部署在这些实例中时，如何将新的Container实例添加到集群。
然后，当CPU较低时，我们会看到调度程序如何开始销毁实例和容器。
一切都很了不起，但有时候，调度程序会销毁一个实例和一个容器，因此，我们的集群在某些时候有1个实例和0个任务，因为它会破坏不同实例中的任务。 我们想要的是一种始终销毁Container实例及其中容器的方法。
我看到＆＃34;终止政策＆＃34;在实例上，但没有任何类似的容器。
我们正在使用容器实例中的比例组和1到5的容器以及基于CPU的指标，以便CPU增长实例和容器增长1到1，我们希望它们以相同的顺序销毁。 / p>
那可能吗？
答案 0 :(得分：0)
我知道这篇文章有点遗漏，但是如果你还在寻找，或者有人发现这个帖子有同样的问题，请让我提供一个答案。
是的，这是可能的，但不是正常的＆＃34;包装＆＃34; ECS的策略。 ECS基本上可以将容器打包或循环使用 - 这与其智能程度有关。它也不够聪明，不知道它应该终止最老实例上的容器（通常是ASG在扩展时终止的容器）。那么如何处理这个问题？
嗯，诀窍是让ASG服务完全处理扩展 。创建规则以在cloudwatch中扩展，并让它们触发Lambda函数。在该Lambda函数中，增加ASG 和ECS服务上的所需计数。是的，ECS将尝试立即执行任务（由于没有足够的CPU /内存可用实例，因此会失败），但是一旦ASG完成实例放置，它就会成功。
向上扩展很容易，缩小比较麻烦。因此，您可以创建缩小规则，并在CPU使用率较低时删除ASG实例。您没有在您的ECS群集上配置缩小规则。完全没有。当ASG终止一个实例时，它将触发一个生命周期规则，说明＆＃34;实例ID X试图终止＆＃34;并且您可以使用SQS（您将配置为启动lambda）来侦听该规则。当您在Lambda中捕获该规则时，您将使用BOTO获取与实例ID关联的任务列表，并调用kill以删除这些特定任务。
只要该任务失效，您就可以将服务上的所需设置为期望-1，这将阻止服务尝试重建任务。
瞧，现在与您的垂死实例关联的任务实例将始终是缩小时终止的实例。
复杂？是的 - ASG真正意味着对与其相关联的集群天真。这会做你想要的。
您可以使用ECS控制所有缩放而不是ASG来模拟相同类型的方法，但这将更加困难，因为您必须轮询已终止的容器而不是能够听取生命周期规则。