当一个弹性负载均衡器（ELB）与一个自动扩展组相关联时，可以指定一个宽限期，在这个宽限期内新的EC2实例即使被ELB标记为不健康，也不会被终止。 是否有可能指定一个类似的宽限期，在此期间，即使运行任务的ECS实例已被ELB标记为不健康，新的ECS任务也不会被其关联的ECS服务终止并重新启动？
更新：
在我们当前的用例中，作为ECS任务运行的docker容器包含一个JBoss实例，在启动时加载一些caching。 这些caching可能需要几分钟才能加载。 但是，一旦容器启动，ECS服务就会使用ELB注册容器实例。 这意味着stream量可以在准备好接受之前路由到新的容器。 我们可以增加ELB的健康检查间隔和“健康/不健康的阈值”，以防止ELB将stream量路由到实例，并且ECS服务重新启动容器，直到caching被加载。 但是，增加健康检查间隔和阈值是不可取的，因为如果一个实例在加载caching后被标记为不健康，ECS服务应该尽快重启容器（这需要较短的健康检查间隔和较小的阈值）。
因此，是否可以应用一个宽限期，在这个宽限期间ELB不会将stream量路由到新的容器，并且ECS服务不会重新启动容器（即使它没有通过健康检查）？ 否则，对于我们的用例的解决scheme有什么build议吗？
经过与支持小组的讨论后发现，ECS不能支持我们目前的使用案例。
有一种解决方法可以解决我们面临的其中一个问题。 该解决方法是创build一个单独的基本健康检查容器，并在与实际应用程序容器相同的ECS任务中创build。 运行状况检查容器的目的是监视应用程序容器，以确定应用程序何时完全启动。 如果检测到应用程序启动失败，则会退出，导致ECS服务循环执行任务。 然后将ELBconfiguration为对健康检查容器执行健康检查，健康检查容器将始终通过相关端口报告它已经启动。 此解决方法将阻止ECS服务由于运行状况检查失败而循环执行ECS任务。
但是，ELB将立即开始将stream量路由到应用程序容器。 即使应用程序容器尚未准备好接收stream量（例如，因为它仍在等待caching加载），它也会这样做。 目前无法延迟ELB向应用容器发送stream量，因为ECS服务不支持宽限期。 我们设法通过SQS提供消息给我们的应用程序容器来解决这个问题，并且只有当它们的caching被完全加载时才从队列中拉出来。 但是，我们有未来的用例（如提供Web请求），这不是一个可行的select。 为此，我打算提出宽限期的function要求。
另外，Kubernetes（ http://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html#application-health-checking ）和Marathon（ https://mesosphere.github.io/马拉松/ docs / health-checks.html ）已经支持这个选项进行健康检查，如果有人读这是很高兴不使用托pipe服务。