Amazon Elastic Container Service
开发人员指南 (API 版本 2014-11-13)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

服务限制逻辑

Amazon ECS 服务计划程序包含限制服务任务在反复启动失败后再启动的频率逻辑。

如果一个 ECS 服务的任务总是无法进入 RUNNING 状态 (直接从 PENDING 跳到 STOPPED),则后续重启尝试间隔的时间会逐渐拉长,最多达到 15 分钟。最长时间将来可能有所变化,并非一成不变。这种机制减少了无法重启的任对您的 Amazon ECS 群集资源或 Fargate 基础设施成本的不利影响。如果您的服务触发了限制逻辑,则您会收到以下服务事件消息

(service service-name) is unable to consistently start tasks successfully.

Amazon ECS 永远不会阻止失败的服务重试,也不会尝试修改服务,除了延长重启的间隔时间外。服务限制逻辑不提供任何用户可调参数。

如果您将服务更新为使用新的任务定义,则您的服务会立即返回到正常的无限制状态。有关更多信息,请参阅 更新服务

以下是触发此逻辑的一些常见原因:

  • 群集中缺乏用来托管任务的资源,如端口、内存或 CPU 单位。在这种情况下,您还会看到资源不足服务事件消息

  • Amazon ECS 容器代理无法提取您的任务 Docker 映像。这可能是因为容器映像名称、映像、标签错误,或者缺少私有注册表身份验证或权限。在这种情况下,您还会在停止的任务错误中看到 CannotPullContainerError

  • 您的容器实例上的磁盘空间不足,无法创建容器。在这种情况下,您还会在停止的任务错误中看到 CannotCreateContainerError。有关更多信息,请参阅 CannotCreateContainerError: API error (500): devmapper

重要

进入 RUNNING 状态后停止的任务不会触发限制逻辑或相关服务事件消息。例如,如果因某个服务的 Elastic Load Balancing 运行状况检查失败而导致某个任务被标记为运行状况不佳,并且 Amazon ECS 取消注册了该服务并终止了该任务,则不会触发限制。即使任务的容器命令立即退出并伴随非零退出代码出现,该任务也已转为 RUNNING 状态。由于命令错误而立刻失败的任务不会触发限制或服务事件消息。