我正在尝试创建某种网络基础设施，并且一直在研究Amazon ECS和Kubernetes。但是，我不太确定这些系统是否做了我实际寻求的东西，或者我是否将它们扭曲为其他东西。如果我能描述我手头的任务，有人可以验证一下 Amazon ECS 或 Kubernetes 是否真的会帮助我完成这项工作，这是思考它的正确方式吗？
我正在尝试做的是在 AWS 实例上进行按需单任务处理。我的意思是，我有一个资源繁重的应用程序，我想在云中运行它，并处理用户提交的大量数据。我想提交要在应用程序上处理的此数据，启动 EC2 实例，处理数据，将结果上传到 S3，然后关闭 EC2 实例。
我已经使用简单队列服务，EC2和Lambda为此构建了一个有效的解决方案。但我想知道 ECS 或 Kubernetes 会让这更简单吗？我一直在浏览 ECS 文档，它似乎不太关心启动和关闭实例。似乎它想要一个持续运行的实例，然后将 docker 映像作为运行任务提供给它。是否可以配置 Amazon ECS，以便在没有任务运行时自动关闭所有实例？
我也不明白我将如何提交要处理的特定数据块。似乎 Amazon ECS 中定义的"任务"实际上对应于单个 Docker 容器，而不是 Docker 容器将处理哪种数据。这是对的吗？那么，我是否仍然需要通过简单的队列服务或其他方式将要处理的数据馈送到实例中？然后使用 Lambda 轮询这些队列，看看它们是否应该向 ECS 提交任务？
这是我现在对此的天真理解，如果有人能帮助我更好地理解我所描述的事情，或者指出我更好的思考方式，将不胜感激。
这是一个复杂的主题，一个好的答案的许多细节取决于您的域/系统的确切要求。因此，以下信息基于您给出的非常高级的描述。
ECS，Kubernetes等的许多功能都旨在允许分布式应用程序充当单个服务，并且可以水平扩展，可升级和维护。这意味着它有助于统一服务接口、负载平衡、服务可靠性、零停机维护、根据需求(或其他指标)增加/减少工作节点的数量等。
下面介绍了针对 kubernetes 使用案例的解决方案的高级想法(它比 AWS ECS 更通用)。
因此，对于您的用例，您可以设置一个运行分布式事件队列的 kubernetes 集群，例如 Apache Pulsar 集群，以及一个正在发送队列事件进行处理的应用程序集群。应用程序集群大小可以根据队列中未处理的事件数自动缩放(自定义 Pod 自动缩放程序)。群集基础架构将配置为根据计划的 Pod 数量自动扩展(Pod 在基础架构上预留容量)。
必须确保应用程序可以在容器中以无状态形式运行。
与当前解决方案相比，我看到的主要好处是云提供商的独立性以及运行容器化系统的一些一般好处：1. 不必担心 EC2 实例在工作负载的操作系统依赖性方面的确切设置。2. 能够将处理应用程序作为单个服务进行处理。3. 潜在地提高可靠性，例如在出现错误的情况下。
关于您的确切问题：
是否可以配置 Amazon ECS，以便在没有任务运行它的情况下 自动关闭所有实例？
这里的关键字是自动缩放。请注意，扩展有两个级别：1. 基础设施扩展(EC2 实例数)和应用程序服务扩展(部署的应用程序容器/任务数)。ECS 基础设施扩展基于 EC2 自动扩展组工作。有关详细信息，请参阅此链接 。有关应用程序服务扩展和无服务器 ECS (Fargate) 的信息，请参阅此链接。
我也不明白我将如何提交具体的 要处理的数据块。似乎像中定义的"任务" Amazon ECS 实际上对应于单个 Docker 容器，而不是那么多 Docker 容器将处理哪种数据。这是对的吗？
ECS 中的"任务定义"描述了如何为某个目的部署一个或多个 docker 容器，以及其环境/限制应该是什么。任务是在"服务"中运行的单个实例，它本身可以部署单个或多个任务。类似的概念是 Pod 和 kubernetes 中的服务/部署。
所以我仍然需要将要处理的数据输入到 实例通过简单队列服务，还是其他？然后使用 Lambda 进行轮询 这些队列以查看它们是否应该向 ECS 提交任务？
队列始终有助于将服务请求与处理分离，并确保不会丢失请求。如果您的应用程序服务集群可以提供服务接口并以可靠的方式直接处理传入的请求，则不需要它。但是，如果您的应用程序集群必须频繁地扩展/缩减，则可能会影响其可靠处理的能力。