amazon-web-services - 启动和关闭适用于 AWS ECS 或 Kubernetes 的实例？

Question

我正在尝试创建某种网络基础设施，并且一直在研究 Amazon ECS 和 Kubernetes。但是，我不太确定这些系统是否能满足我的实际需求，或者我是否将它们扭曲成其他东西。如果我可以描述我手头的任务，是否有人可以验证 Amazon ECS 或 Kubernetes 是否真的会帮助我完成这项工作，这是思考它的正确方式吗？

我想做的是在 AWS 实例上按需进行单任务处理。我的意思是，我有一个资源密集型应用程序，我想在云中运行并处理用户提交的大量数据。我想提交要在应用程序上处理的此数据，启动 EC2 实例，处理数据，将结果上传到 S3，然后关闭 EC2 实例。

我已经使用 Simple Queue Service、EC2 和 Lambda 组合了一个有效的解决方案。但我想知道 ECS 或 Kubernetes 会让这更简单吗？我一直在浏览 ECS 文档，它似乎不太关心启动和关闭实例。似乎它想要一个持续运行的实例，然后将 docker 图像作为要运行的任务提供给它。是否可以配置 Amazon ECS，以便在没有任务运行时自动关闭所有实例？

此外，我不明白我将如何提交要处理的特定数据块。看起来 Amazon ECS 中定义的“任务”确实对应于单个 Docker 容器，而不是 Docker 容器将处理什么样的数据。那是对的吗？那么我是否仍然需要通过简单的队列服务或其他方式将要处理的数据提供给实例？然后使用 Lambda 轮询这些队列，看看它们是否应该向 ECS 提交任务？

这是我现在对此的幼稚理解，如果有人可以帮助我更好地理解我所描述的事情，或者指出我更好的思考方式，将不胜感激。

标签： amazon-web-servicesdockeramazon-ec2kubernetesamazon-ecs

Answer 1

这是一个复杂的主题，一个好的答案的许多细节取决于您的域/系统的确切要求。因此，以下信息基于您提供的非常高级的描述。

ECS、kubernetes 等的许多功能都旨在允许分布式应用程序充当单一服务，并且可以水平扩展、升级和维护。这意味着它有助于统一服务接口、负载平衡、服务可靠性、零停机维护、根据需求（或​​其他指标）向上/向下扩展工作节点的数量等。

下面描述了一个针对您的 Kubernetes 用例（比 AWS ECS 更通用）的解决方案的高级想法。

因此，对于您的用例，您可以设置一个运行分布式事件队列的 kubernetes 集群，例如 Apache Pulsar 集群，以及一个正在发送队列事件进行处理的应用程序集群。您的应用程序集群大小可以根据队列中未处理事件的数量自动扩展（自定义 pod autoscaler）。集群基础设施将配置为根据计划的 pod 数量（基础设施上的 pod 保留容量）自动扩展。

您必须确保您的应用程序可以在容器中以无状态形式运行。

我看到您当前解决方案的主要好处是云提供商的独立性以及运行容器化系统的一些一般好处：1.不必担心您的工作负载的操作系统依赖性方面的 EC2-Instances 的确切设置. 2. 能够将处理应用程序作为单一服务来处理。3. 潜在地增加可靠性，例如在错误的情况下。

关于您的确切问题：

是否可以配置 Amazon ECS，以便在没有任务运行时自动关闭所有实例？

这里的关键字是自动缩放。请注意，有两个级别的扩展： 1. 基础设施扩展（EC2 实例的数量）和应用程序服务扩展（部署的应用程序容器/任务的数量）。ECS 基础架构扩展基于 EC2 自动扩展组工作。有关更多信息，请参阅此链接。有关应用程序服务扩展和无服务器 ECS (Fargate)，请参阅此链接。

此外，我不明白我将如何提交要处理的特定数据块。看起来 Amazon ECS 中定义的“任务”确实对应于单个 Docker 容器，而不是 Docker 容器将处理什么样的数据。那是对的吗？

ECS 中的“任务定义”描述了如何部署一个或多个 docker 容器以达到某个目的，以及它的环境/限制应该是什么。任务是在“服务”中运行的单个实例，该服务本身可以部署单个或多个任务。类似的概念还有 Kubernetes 中的 Pod 和 Service/Deployment。

那么我是否仍然需要通过简单的队列服务或其他方式将要处理的数据提供给实例？然后使用 Lambda 轮询这些队列，看看它们是否应该向 ECS 提交任务？

队列总是有助于将服务请求与处理分离并确保您不会丢失请求。如果您的应用程序服务集群可以提供服务接口并以可靠的方式直接处理传入请求，则不需要。但是，如果您的应用程序集群必须频繁地向上/向下扩展，这可能会影响其可靠处理的能力。