Buildkite流水线中CloudFormation创建ECS Service超时的原因咨询

问题背景 #

夜间运行Buildkite流水线时，CloudFormation创建ECS Service出现超时失败。部署脚本运行15分钟后抛出等待服务部署超时的异常，CloudFormation自身尝试创建服务3小时未果后也最终超时。

参考信息 #

CFN运行日志 #

cfn INFO 03:08:51   CREATE_IN_PROGRESS  build-amis-564-registrations: User Initiated
cfn INFO 03:08:56   CREATE_IN_PROGRESS  TaskDefinition
cfn INFO 03:08:59   CREATE_IN_PROGRESS  TaskDefinition: Resource creation Initiated
cfn INFO 03:08:59   CREATE_COMPLETE TaskDefinition
cfn INFO 03:09:02   CREATE_IN_PROGRESS  ECSService
ecs INFO 03:09:10   Waiting for cluster to scale up. Please wait...
Traceback (most recent call last):
  File ".buildkite/scripts/deploy/ecs_deploy.py", line 282, in <module>
    main()
  File ".buildkite/scripts/deploy/ecs_deploy.py", line 232, in main
    ecs.wait_for_service_steady(cluster, stack_name, project_name, desired_count)
  File "/app/ecs/__init__.py", line 680, in wait_for_service_steady
    raise Exception("Timed out waiting for service deployment")
Exception: Timed out waiting for service deployment

超时逻辑代码片段 #

以下为抛出15分钟超时错误的Python脚本片段（CloudFormation本身会在尝试创建服务3小时失败后超时）：

...
            for event in filter_events_response(response, last_event_id) or []:
                if "insufficient memory" in event["message"]:
                    message = info("Waiting for cluster to scale up. Please wait...")
                else:
                    message = event["message"]

                if log_progress:
                    logger.info(
                        "%s\t%s", event["createdAt"].strftime("%H:%M:%S"), message
                    )

                last_event_id = event["id"]
                waited = 0

                if "steady" in event["message"]:
                    logger.debug(event)
                    return

                if "deregistered" in event["message"]:
                    killed_tasks += 1

                    if killed_tasks > allowed_killed_tasks:
                        raise ServiceUnstableException(
                            "%s-%s service tasks are failing to start"
                            % (stack, service)
                        )

            time.sleep(20)
            waited += 20
            if waited > 900:
                raise Exception("Timed out waiting for service deployment")
...

可能的诱因 #

• 集群自动扩缩容失败：日志明确输出了集群扩容等待提示，说明已经检测到内存不足触发扩容流程。夜间运行时可能出现集群预留资源耗尽、EC2实例配额不足、启动模板配置无效、子网无可用IP、实例启动后无法正常加入ECS集群等问题，导致扩容流程一直无法完成，没有足够资源调度任务。
• 任务长期卡在PENDING状态：如果任务始终处于待调度状态，既没有启动成功进入稳态，也没有报错退出触发注销事件，就不会触发脚本里的返回逻辑或者服务不稳定异常，会一直卡到超时。常见原因包括：镜像拉取失败（ECR权限不足、镜像地址错误、网络波动导致拉取超时）、任务执行角色权限不足无法访问依赖的AWS服务、Secrets Manager/Parameter Store配置错误无法读取配置、容器启动命令异常导致进程卡住不退出。
• ECS服务事件推送延迟：脚本逻辑里只要收到新的服务事件就会重置超时计时器，如果夜间AWS ECS控制面出现延迟，长时间没有推送服务事件，哪怕服务实际已经部署完成，计时器也会持续累加直到超过900秒阈值抛出超时。
• 健康检查配置错误：如果任务启动后健康检查始终失败，ECS会反复销毁异常任务重新调度，如果任务销毁的时间间隔超过脚本20秒的轮询周期，就会出现轮询时抓不到任务注销事件的情况，不会触发失败次数超限的报错，最终卡到超时。
• 基础架构故障：夜间可能出现可用区故障、VPC网络中断、ECS控制面服务降级等底层问题，导致服务调度链路完全中断，CloudFormation和部署脚本都无法获取最新的服务状态，最终双双超时。
• 脚本逻辑缺陷：脚本判断服务进入稳态的条件是事件消息包含steady关键词，如果ECS服务稳态事件的消息格式发生了更新，或者服务事件被自定义修改过，哪怕服务实际已经部署完成，脚本也无法识别到稳态信号，会一直轮询直到超时。

内容的提问来源于stack exchange，提问作者Benjamistan