为什么我们还没迁移到 EKS（尚未）: 生产环境中选择 ECS 而不是 Kubernetes

Source: Dev.to

我们想要避免的 “Kubernetes 税”

Kubernetes 很强大，但它需要在工具和运维上投入大量资源。要在生产环境中正确运行 EKS，你不仅在管理容器，还在管理一个平台。你需要：

• GitOps 工具： ArgoCD 或 FluxCD 用于部署。
• 可观测性： Fluentd 或类似工具用于日志收集。
• Ingress 控制器： NGINX 或 ALB 控制器。
• 安全性： 持续为控制平面和工作节点打补丁。

对我们团队而言，想要 100 % 专注于交付业务代码，而不是管理基础设施的管道。

我们的混合 ECS 架构

我们设计了一套混合 ECS 策略，兼顾无服务器和预配计算的优势。

1. Fargate 用于无状态工作负载

对于主要的应用服务器和 Sidekiq 后台任务，我们使用 ECS Fargate。

• 无需管理服务器： 不需要操作系统补丁或实例扩容。
• 按需付费： 只为任务实际使用的 vCPU 和内存付费。
• 可扩展性： Fargate 能自动处理数千个容器的启动工作。

2. EC2 启动类型用于定时任务

我们并未全部采用 Fargate。对于计划的 cron 任务，我们仍然使用 EC2 Launch Type。

• 为什么？ Cron 任务执行频繁且通常使用相同的基础镜像。
• 成本技巧： 在 EC2 实例上运行可以本地缓存 Docker 层，显著降低从 ECR 的数据传输费用并加快启动时间——这是 Fargate 对于频繁、短暂任务的支持不够高效的地方。

技术栈：简洁且托管

我们将状态管理交给 AWS 托管服务，以保持计算层完全是临时的：

• 数据库： Amazon RDS for PostgreSQL。
• 缓存： Amazon ElastiCache（Redis）。

CI/CD：省去繁琐

最大的收获之一是避免了 ArgoCD 或 Flux 那样的 “GitOps” 复杂度。我们的流水线是一个直接的 GitHub Actions 工作流：

1. 构建： 创建 Docker 镜像。
2. 扫描： 运行安全漏洞扫描。
3. 推送： 上传至 ECR。
4. 部署： 更新 ECS 任务定义并强制新部署。

就这么简单。没有单独的同步服务器、没有复杂的 CRD，也不需要管理 Helm Chart。流水线稳健、易于调试，且几乎不需要维护。

结论：时间就是金钱

选择 ECS，我们：

• 跳过学习曲线： 无需让团队学习 kubectl、manifest 或集群网络。
• 降低运维开销： 不需要节点打补丁，也不需要控制平面升级。
• 削减费用： 没有 EKS 控制平面费用（每个集群 $73 / 月）或工作节点上的系统 Pod 开销。

如果将来对自定义网络或服务网格的需求足够复杂，我们可能会迁移到 EKS。但目前，ECS 让我们能够运行一个稳定、高性能的生产环境，唯一需要关注的就是我们的业务代码。

有时候，最好的工程决策恰恰是最“无聊”的那一个。