通过 AWS Fargate 实现无服务器容器运维 - ECS 与 EKS 的应用模式
介绍无需实例管理的无服务器容器，包括 ECS 与 EKS 的使用场景区分以及通过任务大小调整进行成本优化的方法。
Fargate 的工作原理及与 EC2 启动类型的区别
Fargate 是 ECS 和 EKS 的无服务器计算引擎。EC2 启动类型需要自行管理运行容器的 EC2 实例的预置、扩展和补丁更新，而 Fargate 将这些完全抽象化。只需在任务定义中指定 vCPU（0.25 到 16）和内存（0.5 GiB 到 120 GiB），AWS 就会自动预置容器的运行环境。每个任务在基于 Firecracker 的独立 microVM 中运行，任务间不共享内核，安全隔离得到增强。无法访问底层主机 OS，也无法运行特权容器。平台版本（ECS）管理 OS 内核和运行时版本，指定 LATEST 会自动应用最新稳定版。
ECS on Fargate 与 EKS on Fargate 的使用场景区分
ECS on Fargate 是 AWS 原生的容器编排，通过任务定义、服务和集群三个概念即可简单运维。标准提供与 ALB 的集成、通过 Service Connect 实现的服务网格以及通过 CloudMap 实现的服务发现。ECS Exec 可连接交互式 Shell 到任务内的容器，用于生产环境调试。EKS on Fargate 在 Fargate 上运行 Kubernetes Pod。通过 Fargate Profile 定义命名空间和标签选择器，匹配条件的 Pod 自动调度到 Fargate。当需要利用 Kubernetes 生态系统（Helm、Argo CD、Prometheus 等）或在多云环境中推进 Kubernetes 标准化时选择此方案。但 EKS on Fargate 存在无法使用 DaemonSet、无法挂载 EBS 卷（支持 EFS）、不支持 GPU 实例、每个 Pod 分配 ENI 导致启动比 EC2 节点慢等限制。
成本优化
Fargate 按 vCPU 秒和内存 GB 秒按量计费。合理调整任务大小是成本优化的关键。通过 CloudWatch Container Insights 测量实际 CPU 和内存使用率，减少过度预置的任务资源。Fargate Spot 可享受最高 70% 的按需折扣，中断时发送 SIGTERM 信号后有 30 秒的宽限期。适用于基于队列的 Worker 和批处理等具有中断容忍性的工作负载。Compute Savings Plans 可跨 Fargate、Lambda 和 EC2 应用，1 年承诺最高可获 50% 折扣。 如需系统学习 Fargate，可参考相关书籍 (Amazon)。
设计最佳实践与常见陷阱
vCPU 和内存的组合存在有效值矩阵，不能指定任意组合（例如 0.25 vCPU 仅可选择 0.5/1/2 GiB）。如果未正确设置健康检查宽限期 (healthCheckGracePeriodSeconds)，启动较慢的容器会因健康检查失败而进入停止-重启的无限循环。临时存储默认为 20 GiB（最大 200 GiB），任务终止时消失，因此持久数据应使用 EFS 或 S3。awsvpc 网络模式是必须的，由于每个任务分配一个 ENI，需注意子网 IP 地址耗尽。运行大量任务时，请确保至少 /19 的 CIDR 或启用 ENI Trunking。
Fargate 与 App Runner 的比较
App Runner 是比 Fargate 抽象度更高的容器服务，从源代码或容器镜像自动构建、部署和扩展。无需 VPC 配置或任务定义，是部署 Web 应用和 API 的最快路径。而 Fargate 提供 VPC 内部署、细粒度安全组控制、Sidecar 容器、多容器任务定义、EFS 挂载和 GPU 支持（EC2 启动类型）等高级网络和自定义功能。稳定流量的 Web API 适合 App Runner，批处理、多容器配置以及需要直接访问 VPC 资源的工作负载则适合 ECS on Fargate。EKS on Fargate 在需要复用现有 Kubernetes 清单和工具链时选择。
总结
Fargate 是从容器运维中消除基础设施管理的无服务器计算引擎。可从 ECS on Fargate 简单起步，需要 Kubernetes 时迁移到 EKS on Fargate。利用 Fargate Spot 和 Savings Plans 优化成本，通过 Container Insights 持续监控资源使用率非常重要。理解子网 IP 耗尽、vCPU/内存有效组合、健康检查设置等典型陷阱，可实现稳定的生产运维。