AWS ECS EC2滚动更新提示CPU单元不足的配置咨询

调度逻辑认知偏差 #

你对ECS服务部署配置的最低健康百分比、最高百分比规则存在误解：
以当前服务期望运行2个任务、配置为50%最低健康/200%最高百分比为例，ECS的实际调度规则是：

• 滚动更新全程，最少保持1个健康的任务实例运行（2*50%=1，不允许在无任何健康任务的状态下进行更新）
• 滚动更新过程中，新旧版本任务的总数量最多允许达到4个（2*200%=4）
  ECS的默认滚动更新流程是优先在集群空闲资源中拉起新版本任务，待新任务通过健康检查后，再逐步下线旧版本任务，直到全量替换完成。和你预期的“先停旧任务腾资源、再启动新任务”的流程完全相反。

资源测算缺口 #

你当前集群仅注册1台t3a.small实例，总可调度资源为2048CPU单位、1961MiB内存。
现有2个运行中的旧任务，每个任务需要申请900CPU单位、900MiB内存（ECS调度时以任务级定义的资源值为准，容器级的资源配置仅影响运行时的cgroup限制，不参与调度资源计算），两个旧任务合计占用1800CPU、1800MiB，剩余可调度空闲资源仅248CPU、161MiB。
按原部署配置，ECS第一步需要调度拉起1个新版本任务，该任务需要申请900CPU单位，当前剩余的248CPU远达不到调度要求，ECS根本不会进入“停止旧任务释放资源”的流程，直接抛出资源不足的放置失败报错。
按原配置推算，要支撑新旧任务并行，需要至少能容纳3个任务的资源（2个旧+1个新），合计需2700CPU，远超单台t3a.small的2048总CPU容量，必然触发调度失败。

方案1：调整永久部署配置，适配单节点资源上限 #

如果集群长期维持单台节点的规模，可以把Terraform中定义的ECS服务部署配置调整为：最低健康百分比=0%，最高百分比=100%
这套配置的调度规则是：

• 滚动更新全程，最少允许0个健康任务（即可以先下线旧任务，空出资源再启动新任务）
• 滚动更新过程中，新旧任务总数量最多等于期望运行数（2个），不会尝试超配资源拉起新任务
  调整后更新流程为：先下线1个旧任务，空出900CPU、900MiB资源，在空闲资源上拉起新版本任务，待新任务健康后，再下线最后1个旧任务，在空出的资源上拉起第二个新版本任务，全程不会触发资源不足报错。

注意：这套配置下，滚动更新过程中会短暂出现服务无可用实例的阶段，存在极短时间的服务中断，适合可容忍短暂中断的单节点部署场景。

方案2：临时调整参数完成本次部署 #

如果暂时不想修改Terraform中的永久配置，可以在执行更新命令时，临时指定部署配置参数绕过资源限制，命令示例：

aws ecs update-service --cluster $(ECS_CLUSTER) --service $(ECS_SERVICE) --force-new-deployment --task-definition $(ECS_TASK_DEFINITION) --deployment-configuration '{"maximumPercent":100,"minimumHealthPercent":0}'

待后续扩容集群节点、保留原高可用配置时，再把部署参数改回50%/200%即可。

方案3：扩容集群节点，保留原配置的高可用性 #

如果不希望滚动更新过程中出现服务中断，可以给ECS集群新增至少1台同规格的t3a.small实例，集群整体可调度资源翻倍后，即使保留原50%/200%的部署配置，也有足够的空闲资源并行拉起新旧任务，实现零中断滚动更新。

你当前的任务级配置和容器级配置存在资源值差异：任务级定义了900CPU单位，容器级仅定义256CPU单位。ECS调度时会严格以任务级的资源申请值作为调度依据，容器级的CPU配置仅在运行时生效，用来限制容器的CPU使用优先级，不会减少调度时向集群申请的资源量，做资源容量规划时需要以任务级的配置值为准，避免测算偏差。

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