我有一个系统，每天需要部署数十万个短期作业。每个作业的运行时间从几秒钟到几个小时不等。每个作业都会向外部 Web 服务器发出 HTTP 请求，将数据写入磁盘（从几兆字节到几百千兆字节不等），并与数据库建立一系列连接。
每个作业都是同一个 Docker 容器，运行同一个 Java 进程。每个作业都有不同的配置，以环境变量的形式传递。
我们目前使用“作业”规范在 Kubernetes 集群上部署这些作业。但是，当需要运行大量作业时，集群无法立即用于作业。我们还必须不断查询 Kubernetes 集群以确定作业是否已完成或被终止（例如内存不足）。
我希望找到一个解决方案，使我们能够尽快部署这些作业，而不用担心资源是否可用，或者要求我们查询系统来确定作业是否已完成。
我想到的是 AWS Lambda，但我对它没有什么经验。
作为架构说明，我们有一个为调度程序提供服务的流程，该流程计算应该运行什么作业以及何时运行。该流程当前将作业提交给 Kubernetes 集群。
鉴于上述描述，我应该评估什么样的架构来尽量减少该系统对以下方面的关注：1）是否有可用资源来处理该工作；2）该工作是否因任何“非应用”原因而失败。
该系统目前在 GCP 和 AWS 上运行。我们愿意接受任何解决方案，即使这意味着要选择一个（可能不同的）平台。
答案1
如果作业的生命周期很短，那么实施作业队列和一组生命周期较长的工作者（这些工作者会从队列中使用作业）可能更能达到您的目的。您是否需要在 k8s 本身中运行作业？
答案2
假设您的集群资源有限。如果要实现更高的作业量，则必须使用更高效的应用程序或更多资源。
像您使用的大型提供商会根据您的预算向您出租尽可能多的实例。扩展您的集群，可能自动扩展。如果您在短时间内安排工作，可能需要一些备用容量。
轮询 Kubernetes 作业的另一种方法是通过代码传递消息。在作业结束时，对调度程序进行某种回调以指示已完成。
当然，它可能已经死亡并且永远不会报告。最终这需要成为一种失败状态。考虑在典型的最短作业时间之后每隔一段时间轮询该作业，并在达到硬性限制后放弃它，例如 activeDeadlineSeconds。