Published on

AWS ECS Intro

Authors
  • avatar
    Name
    Guming
    Twitter

介绍

Amazon ECS 中有三个层

  • Capacity 容器运行的底层infra(EC2/Fargate/On-premises VM)
  • Controller 部署和管理在容器上运行的应用程序
  • Provisioning 工具。与调度器交互，以部署和管理 的应用程序和容器
本地图片1

ECS Application lifecycle

本地图片1
  1. 生成docker image，放置ECR
  2. 定义Task, 一个 JSON 格式的文本文件，描述了构成应用程序的参数和一个或多个容器,可以使用它来指定操作系统image和参数、要使用的容器、为应用程序打开的端口以及任务中容器使用的数据卷等
  3. 应用部署服务至集群
  4. 使用 Amazon ECS 服务在 Amazon ECS 集群中同时运行并维护所需数量的任务。其工作原理是，如果任务失败或停止，Amazon ECS 服务调度器将根据任务定义启动另一个实例来替换它，从而保持服务中所需任务数量
本地图片1

5.部署任务或服务后， 可以使用以下任何工具来监控:

  • CloudWatch
  • Runtime Monitoring

容量与网络

  • Capacity

    • 创建集群时， 指定基础设施（称为集群默认基础设施）。在注册任务定义时，指定基础设施类型（任务定义基础设施级别，如果未指定，则使用集群默认基础设施）
    • Fargate类型 无服务器、按使用付费的计算引擎
      • 适合需要减少ops成本的场景
      • 批量任务场景
      • 偶尔出现突发流量的场景
      • 小型任务 本地图片1
    • EC2 启动类型适用于需要价格优化的较大工作负载
      • 可以将容器与弹性负载均衡负载均衡器关联起来
    • On-premises
      • Amazon ECS Anywhere 支持将外部实例（如本地服务器或虚拟机）注册到 的 Amazon ECS 集群中。外部实例针对运行产生出站流量或处理数据的应用程序进行了优化。如果 的应用程序需要入站流量，由于缺乏弹性负载均衡支持，运行这些工作负载的效率会降低。Amazon ECS 添加了一种新的 EXTERNAL 启动类型， 可以使用它在外部实例上创建服务或运行任务 本地图片1

  • Networking

    • ECS部署在private subnet

    • Internet to ECS

      • ALB/NLB
        • public subnet
      • API Gateway
        • 通过vpc link ,将流量转发到ecs

    • ECS to VPC

      • NAT gateway (public subset) - 其实前面还有一个Internet gateway
        • NAT 网关对通过它的每 GB 数据收费
        • 无法限制 NAT 网关可以与之通信的目的地。也无法限制后端与目的地的通讯
      • PrivateLink
        • AWS PrivateLink 在子网内部提供弹性网络接口（ENI），并使用 VPC 路由规则将任何通信通过 ENI, 直接到达目标 AWS 服务。这种流量不再需要使用 NAT 网关或互联网网关

    • VPC to ECS

      • Service Connect
        • 它为服务发现、连接和流量监控提供 Amazon ECS 配置。使用服务连接，应用程序可以通过短名称和标准端口连接到同一集群中的服务、其他集群，甚至跨同一区域内的 VPC 本地图片1
      • AWS Cloud Map 本地图片1
      • LB -服务间通信的另一种方法是使用内部负载均衡器。内部负载均衡器完全存在于你的 VPC 内部，并且只能被 VPC 内部的服务访问 本地图片1

监控

资源监控

如果使用 Fargate launch type来运行服务，提供 CPU 和内存利用率指标，以帮助监控服务

对于 Amazon EC2 工作方式,首先监控ec2 instace ,紧接着在集群、服务和任务级别，提供 CPU 、内存预留 和利用率指标

总结下，监控的基准base：

  • Amazon ECS 集群的 CPU 和内存预留及使用指标
  • Amazon ECS 服务的 CPU 和内存使用指标
  • Amazon ECS 任务级别的监控

监控工具和告警

Amazon CloudWatch alarms - 指定时间范围内的单个指标，并根据指标值相对于给定阈值在多个时间范围内的变化执行一个或多个操作。该操作是发送到 Amazon 简单通知服务 (Amazon SNS) 主题或 Amazon EC2 自动扩展策略的通知。

Amazon CloudWatch Logs - Application logs

Amazon CloudWatch Events - 匹配事件并将它们路由到一个或多个目标函数或流，以进行更改、捕获状态信息并采取纠正措施

Container Insights - 使用 Container Insights 监控 Amazon ECS 容器

Runtime Monitoring - GuardDuty 运行时监控使用 GuardDuty 安全代理，为单个 Amazon ECS 工作负载添加运行时可见性，例如文件访问、进程执行和网络连接

使用 EventBridge 自动响应 Amazon ECS 错误

使用 Container Insights 监控 Amazon ECS 容器，以增强可观察性

使用容器健康检查确定 Amazon ECS 任务健康

当任务定义中定义了健康检查时，容器会在容器内部运行健康检查进程，然后根据退出代码评估应用程序的健康状况

按顺序评估以下规则：

如果一个关键容器的状态是 UNHEALTHY ，那么任务状态是 UNHEALTHY

如果一个关键容器的状态是 UNKNOWN ，那么任务状态是 UNKNOWN

如果所有关键容器的状态都是 HEALTHY ，那么任务状态是 HEALTHY

使用 ECS Exec 监控 Amazon ECS 容器

ECS 集群

Amazon ECS 集群是任务或服务的逻辑分组。除了任务和服务外，集群还包含以下资源：

基础设施容量提供者 的工作负载和服务的网络（VPC 和子网） 一个可选的命名空间：命名空间用于通过 Service Connect 进行服务间通信。

适用于 Fargate 启动类型的 ECS 容量提供者

每个集群可以有一个或多个capacity provider，以及一个可选的容量提供者策略。容量提供者策略决定了任务如何在集群的容量提供者之间分配。当运行独立任务或创建服务时，要么使用集群的默认容量提供者策略，要么使用覆盖默认策略的容量提供者策略。

当 在 AWS Fargate 上运行任务时， 不需要创建或管理容量。 只需要将以下预定义的任何容量提供者与集群关联：

  • Fargate
  • Fargate Spot

使用 Fargate Spot， 以在比 Fargate 价格更低的折扣率下运行容错性 Amazon ECS 任务。Fargate Spot 在备用计算能力上运行任务。当 AWS 需要回收容量时，任务会收到两分钟的警告并被中断

适用于 EC2 启动类型的 ECS 容量提供者

Amazon EC2 实例作为容量时，使用自动扩展组来管理注册到其集群的 Amazon EC2 实例。自动扩展有助于确保有正确数量的 Amazon EC2 实例来处理应用程序负载

可以使用托管扩展功能，让 Amazon ECS 管理自动扩展组的扩展和缩减操作，或者可以自行管理扩展操作

本地图片1

Amazon EC2 实例的优雅终止 - Draining Amazon ECS 容器实例“服务流程”

本地图片1

Draining 过程中，处于 PENDING 或 RUNNING 状态下的任何独立任务都不会受到影响；你必须等待它们自行停止或手动停止它们。容器所在实例将保持 DRAINING 状态

一个容器实例完成排空时，该实例上运行的所有任务都会转变为 STOPPED 状态。容器实例将保持 DRAINING 状态，直到再次被激活或被删除

参数

  • minimumHealthyPercent ：此参数设置在替换过程中必须保持运行和健康任务数量的下限

如果你有一个 desiredCount 为 4 个任务的服务，并将 minimumHealthyPercent 设置为 50%，调度器将确保在任何给定时间至少有 50% 的任务（即 2 个任务）保持健康和运行

  • maximumPercent ：此参数设置了在替换过程中可以同时运行的任务总数（现有任务和新任务）的上限

当 desiredCount 设置为 4 个任务且 maximumPercent 设置为 200% 时，调度器允许在替换期间最多同时运行 8 个任务（4 个当前任务 + 4 个新任务）

注意事项

  • Running Tasks 如果在注销时容器实例上存在活动任务，它们将继续运行，直到自然停止或实例被终止。但是，这些任务将成为孤儿任务，这意味着 ECS 将不再监控或管理它们。对于属于服务中的任务，服务调度器将尝试在其他可用实例上启动替换任务

  • Instance Termination 注销一个容器实例并不会自动终止其底层的 EC2 实例。如果 不再需要该实例， 应该手动终止它以避免产生不必要的费用

  • Auto Scaling Groups and CloudFormation 果容器实例由自动扩展组或 AWS CloudFormation 堆栈管理，建议更新自动扩展组或 CloudFormation 堆栈以终止该实例。这种方法可以防止自动创建一个新的实例来替换已终止的实例。

Draining vs Deregistering

本地图片1

ECS container agent

ECS 代理是在注册到集群的每个容器实例上运行的进程。负责容器实例和 Amazon ECS 之间的通信

本地图片1

ECS 任务定义

Task definition - 可以将任务定义作为任务或服务来运行

Task definition states

  • ACTIVE: 任务定义在注册到 Amazon ECS 后处于 ACTIVE 状态。可以使用处于 ACTIVE 状态的任务定义来运行任务或创建服务

  • INACTIVE: 任务定义在 注销任务定义时从 ACTIVE 状态过渡到 INACTIVE 状态

  • DELETE_IN_PROGRESS: 任务定义在提交删除任务定义后从 INACTIVE 状态过渡到 DELETE_IN_PROGRESS 状态, 务定义进入 DELETE_IN_PROGRESS 状态后，Amazon ECS 会定期验证目标任务定义是否未被任何活 动任务或部署引用，然后永久删除任务定义

最佳实践

building image

在设计和构建 的容器镜像时，请遵循以下指南：

通过将所有应用程序依赖项作为静态文件存储在容器镜像内部，使容器镜像完整

在容器内运行单个应用程序进程

使应用程序处理 SIGTERM信号， 当 Amazon ECS 停止任务时，它首先向任务发送 SIGTERM 信号，通知应用程序需要完成并关闭。然后 Amazon ECS 发送 SIGKILL 消息。当应用程序忽略 SIGTERM 时，Amazon ECS 服务必须等待发送 SIGKILL 信号来终止进程

需要确定应用程序完成其工作所需的时间，并确保应用程序能够处理 SIGTERM 信号。应用程序的信号处理需要阻止应用程序接收新request，或者在处理业务所需时间过长时将未完成的工作保存到任务外部的存储中。

本地图片1
本地图片1
  • 将日志处理与应用程序代码解耦
  • 使用标签对容器镜像进行版本控制：不必为每个提交构建一个容器镜像。但是，建议每次将特定的代码提交发布到生产环境时都构建一个新的容器镜像

task sizes

在 ECS 中，CPU 和内存是用于容量的两个资源指标。CPU 以 1/1024 个完整 vCPU 的单位进行衡量。内存以兆字节为单位进行衡量

任务定义中，可以配置资源预留和限制 - container

ECS 配置

ECS 的 IAM 角色配置

本地图片1

EC2 启动类型的 Amazon ECS 网络选项

  • AWSVPC network mode （推荐）

Amazon ECS Task具有与 Amazon EC2 实例相同的网络属性,如sg/vpc flow logs等

本地图片1

ECS 创建 ENI 并将其附加到具有指定安全组的宿主 Amazon EC2 实例。任务通过 ENI 发送和接收网络流量，就像 Amazon EC2 实例通过其主网络接口一样。每个任务 ENI 默认分配一个私有 IPv4 地址。如果 VPC 启用了双栈模式，并且使用具有 IPv6 CIDR 块的子网，任务 ENI 还将接收一个 IPv6 地址。每个任务只能有一个 ENI

  • Host network mode

Host 网络模式仅支持托管在 Amazon EC2 实例上的 Amazon ECS 任务。在使用 Fargate 上的 Amazon ECS 时，不支持此模式

Host 网络模式是 Amazon ECS 中支持的最基本的网络模式。使用 Host 模式时，容器的网络直接绑定到运行该容器的底层宿主机

使用此网络模式存在显著的缺点。无法在每个主机上运行超过一个任务实例。

  • Bridge network mode

桥接网络模式仅适用于在 Amazon EC2 实例上托管的 Amazon ECS 任务。

使用桥接模式，可以使用虚拟网络桥在主机和容器的网络之间创建一个层。 这样，可以创建端口映射，将主机端口重新映射到容器端口。 映射可以是静态的，也可以是动态的。

使用 bridge 网络模式的一个缺点是难以锁定服务间的通信。由于服务可能被分配到任意随机的未使用端口，必须在主机之间开放较广的端口范围。很难创建特定规则以使某个服务只能与另一个特定服务通信，因为这些服务没有用于安全组网络规则的固定端口。

ECS 的存储选择

| Data Volume | Supported Launch Types | Supported Operating Systems | Storage Persistence | Use Cases |
|---|---|---|---|---|
| Amazon Elastic Block Store (Amazon EBS) | Fargate, Amazon EC2 | Linux | Can be persisted when attached to a standalone task. Ephemeral when attached to a task maintained by a service. | Amazon EBS volumes provide cost-effective, durable, high-performance block storage for data-intensive containerized workloads. Common use cases include transactional workloads such as databases, virtual desktops and root volumes, and throughput-intensive workloads such as log processing and ETL workloads. |
| Amazon Elastic File System (Amazon EFS) | Fargate, Amazon EC2 | Linux | Persistent | Amazon EFS volumes provide simple, scalable, and persistent shared file storage for use with your Amazon ECS tasks that grows and shrinks automatically as you add and remove files. They support concurrency and are useful for containerized applications that scale horizontally and need storage functionalities like low latency, high throughput, and read-after-write consistency. Common use cases include data analytics, media processing, content management, and web serving. |
| Docker Volumes | Amazon EC2 | Windows, Linux | Persistent | Docker volumes are a feature of the Docker container runtime that allow containers to persist data by mounting a directory from the file system of the host. They can be managed by third-party drivers or by the built-in `local` driver. Common use cases include providing persistent data volumes or sharing volumes at different locations on different containers on the same container instance. |
| Bind Mounts | Fargate, Amazon EC2 | Windows, Linux | Ephemeral | Bind mounts consist of a file or directory on the host, such as an Amazon EC2 instance or AWS Fargate, that is mounted onto a container. Common use cases include sharing a volume from a source container with other containers in the same task, or mounting a host volume or an empty volume in one or more containers. |

ECS Schedule 选择

Option | When to use
------- | --------
Service | The service scheduler is suitable for long running stateless services and applications. The service scheduler optionally also makes sure that tasks are registered against an Elastic Load Balancing load balancer. You can update your services that are maintained by the service scheduler. This might include deploying a new task definition or changing the number of desired tasks that are running. By default, the service scheduler spreads tasks across multiple Availability Zones. However, you can use task placement strategies and constraints to customize task placement decisions.
Standalone task | A standalone task is suitable for processes such as batch jobs that perform work and then stop. For example, you can have a process call RunTask when work comes into a queue. The task pulls work from the queue, performs the work, and then exits. Using RunTask, you can allow the default task placement strategy to distribute tasks randomly across your cluster. This minimizes the chances that a single instance gets a disproportionate number of tasks.
Scheduled tasks | A scheduled task is suitable when you have tasks to run at set intervals in your cluster, you can use EventBridge Scheduler to create a schedule. You can run tasks for a backup operation or a log scan. The EventBridge Scheduler schedule that you create can run one or more tasks in your cluster at specified times. Your scheduled event can be set to a specific interval (run every $$N$$ minutes, hours, or days). Otherwise, for more complicated scheduling, you can use a cron expression.

ECS task lifecycle

PROVISIONING ｜ PENDING ｜ ACTIVATING ｜ RUNNING ｜ DEACTIVATING ｜ STOPPING ｜ DEPROVISIONING ｜ STOPPED ｜ DELETED

Task Placement

任务放置策略（Task placement strategy）

这是用于选择容器实例（EC2 实例）以放置任务，或选择要终止任务的算法。 例如，Amazon ECS 可以随机选择容器实例，也可以选择使任务在一组实例中均匀分布的容器实例

只适用于EC2 launch type

Task group — 一组相关的任务，例如数据库任务

任务放置约束（Task placement constraint）：

这些是放置任务时必须满足的规则。如果未满足约束条件，任务将无法放置，并保持在 PENDING（等待）状态

只适用于EC2 launch type

ECS standalone tasks

适合 Standalone Tasks 的情况：

  • 批处理作业：数据处理、报表生成
  • 一次性任务：数据库迁移、数据清理
  • 测试部署：临时测试容器配置
  • 开发调试：开发环境中的临时容器

Optimize Task launch time

  1. 基础设施预热策略 EC2 实例预热：

预先运行 EC2 实例并保持运行状态 避免冷启动导致的实例启动延迟 使用 Auto Scaling 组维护最小实例数量 Fargate 优化：

Fargate 本身已优化冷启动时间 选择合适的内存和 CPU 配置（过小配置可能导致启动变慢）

  1. 镜像优化策略 镜像大小优化：

使用多阶段构建减少镜像大小 移除不必要的依赖和文件 使用 Alpine Linux 等轻量级基础镜像 镜像层缓存：

合理安排 Dockerfile 指令顺序 将频繁变化的层放在最后 利用 ECR 的镜像缓存机制

  1. 网络优化策略 镜像拉取优化：

使用 ECR 私有端点（避免 NAT 网关延迟） 在 VPC 内配置 ECR 端点 使用 AWS PrivateLink 减少网络跳数 子网策略：

在多个可用区部署任务 使用靠近服务的子网 避免跨可用区的网络延迟 4. 任务定义优化 资源规格匹配：

精确配置 CPU 和内存需求 避免过度分配资源 使用 Fargate 的精确资源配置 启动类型选择：

Fargate：适合快速启动，无需基础设施管理 EC2：适合大规模、价格优化的场景，但需要实例预热

  1. 服务配置优化 期望任务数量：

维持适当的期望任务数量 避免从零开始的扩展延迟 使用 Auto Scaling 预测性扩展 部署策略：

使用滚动部署减少服务中断 配置适当的健康检查宽限期 优化任务停止超时设置

schedule ECS tasks

EventBridge/CloudWatch Events

ECS services

ECS Service 是 Amazon ECS 中用于 运行和维护应用程序 的关键机制。
它的核心职责是让集群中始终保持 期望数量（desired count） 的任务处于运行状态。

无论是应用升级、实例故障还是扩展需求，Service 都能自动响应，保证服务的稳定性和一致性。

Service 的核心功能

任务数量维护

  • 自动维持任务数量：确保集群中始终有指定数量的任务实例在运行。
  • 故障自动恢复：当某个任务失败或停止时，ECS Service Scheduler 会自动创建新的任务实例进行替换。
  • 持续监控：Service 会持续监测任务运行状态，并在检测到故障时自动修复。

与 Task 的关系

ECS 中的任务（Task）可以分为两类：

  • Service Tasks：由 Service 管理和调度，具备自动恢复与负载均衡能力。
  • Standalone Tasks：独立运行的任务，不受服务控制，适用于临时任务或一次性执行。

Service 配置选项

负载均衡器集成

ECS Service 可以直接与以下负载均衡器整合：

  • Application Load Balancer (ALB)：适用于 HTTP/HTTPS 应用，支持路径与主机路由。
  • Network Load Balancer (NLB)：适用于 TCP、UDP 等非 HTTP 协议，延迟更低。

扩展与版本更新

  • 水平扩展（Scaling）：通过修改 desiredCount 扩展或缩减任务数量。
  • 版本更新（Deployment）：部署新的容器镜像版本。
  • 滚动部署（Rolling Update）：实现零停机更新，逐步替换旧版本任务。

Service 架构模式

容器分组策略

不同的应用组件可以通过任务定义（Task Definition）灵活组合：

  • 相关容器一起运行：将需要紧密协作的容器（如 Web 与 Sidecar 日志代理）定义在同一任务中。
  • 组件分离部署：将不同功能模块（如前端、后端、数据库代理）分离为多个 Service，以便独立扩展与管理。

ECS Service自动扩展

自动扩展（Automatic Scaling） 是指根据负载情况，自动增加或减少 ECS Service 中任务数量 的能力。
Amazon ECS 借助 Application Auto Scaling 服务实现这一功能。

CloudWatch 指标与扩展逻辑

Amazon ECS 会向 CloudWatch 发布服务的平均 CPU 和 内存使用率 指标。

你可以利用这些指标（以及其他自定义 CloudWatch 指标）来：

  • 扩展服务（Scale Out）：在高峰时段自动增加任务数量，以应对更高的负载；
  • 收缩服务（Scale In）：在低负载期间自动减少任务数量，从而节省成本。

ECS Service 自动扩展的四种类型

  • 基于目标指标的扩展（Target Tracking） 根据特定指标（如 CPU 或内存使用率）的目标值自动调整任务数量。
    这类似于家里的恒温器：你设定温度，系统会自动保持稳定。

示例：

  • 设定目标 CPU 利用率为 70%
  • 当平均利用率高于 70% 时，自动增加任务
  • 当低于 70% 时，自动减少任务
  • 基于阈值阶梯的扩展（Step Scaling） 根据 CloudWatch 报警（Alarm）触发的不同阈值，执行不同幅度的扩展或收缩操作。
    这种方式依赖于 阶梯调整（Step Adjustments），可根据报警严重程度定义不同的任务调整幅度。

示例：

  • CPU > 80% → 增加 2 个任务
  • CPU > 90% → 再增加 4 个任务
  • CPU < 30% → 减少 1 个任务
  • 基于计划任务的扩展（Scheduled Scaling） 根据时间计划表，在指定日期或时间自动调整任务数量。
    这种方式适合应对可预测的流量模式，例如工作日和周末的访问差异。

示例：

  • 每天上午 9:00 扩展至 10 个任务
  • 每天晚上 10:00 缩减至 3 个任务
  • 基于历史趋势的预测扩展（Predictive Scaling） 利用历史负载数据分析，自动识别 每日或每周的流量模式，并提前调整任务数量。
    这种方式通过 流量预测（Predictive Analytics） 提前扩展或收缩服务，以平滑应对峰值波动。

示例：

  • 系统分析过去两周的访问趋势
  • 自动预测每天上午 10 点左右为访问高峰
  • 在高峰来临前 15 分钟提前扩容

保护 Amazon ECS Service 任务免于被缩容事件终止

在 Amazon ECS 中，你可以使用 任务缩容保护（Task Scale-In Protection） 来防止任务在 服务自动扩缩容（Service Auto Scaling） 或 部署（Deployment） 时被意外终止。

为什么需要任务保护？

某些关键型应用程序需要一种机制，来确保在 低负载 或 部署更新 期间不会错误终止正在运行的重要任务。
例如：

  1. 🎬 异步队列处理任务
    比如视频转码服务中的任务，有些任务可能需要运行数小时。即使整体服务利用率较低，也必须让这些任务继续运行直到完成。

  2. 🎮 游戏服务器应用
    游戏服务器作为 ECS 任务运行，即使当前所有用户都已下线，也需要保持任务持续运行，以减少重启服务器的启动延迟。

  3. 🚀 部署期间保持任务运行
    当你部署新的代码版本时，某些任务必须保持运行状态，因为重新处理任务的代价过高。

如何启用任务保护

为了防止你的服务任务在缩容（scale-in）事件中被终止，可以将任务的属性 protectionEnabled 设置为 true。

{
  "protectionEnabled": true
}
Discuss on Twitter • View on GitHub