我有一个独特的用例，我想一次运行大量（数千到数万个）Kubernetes 作业。每个作业由一个容器、Parallelism 1 和 Completions 1 组成，没有边车或代理。我的集群有足够的容量来满足我请求的资源。
我的问题是当我同时运行许多作业时，作业状态在很长一段时间内都没有转换为完成。
我的应用程序提交作业并在命名空间上有一个观察者 - 一旦作业的状态转换为“成功 1”，我们就会删除该作业并将信息发送回应用程序。应用程序需要尽快执行此操作，以便定义和提交后续作业。
我能够以我想要的速度提交新的作业请求，并且 Pod 调度不会延迟，但是超过大约一两百个并发作业时，我会在作业的 Pod 完成和作业的状态更新为 Complete 之间出现明显的延迟。集群中只有大约 1,000 个作业，更新作业状态可能需要 5-10 分钟。
这告诉我 Kubernetes 控制平面中的某些进程需要更多资源来更快地处理 Pod 完成事件，或者需要一个配置选项来使其能够并行处理更多任务。但是，我的系统监控工具尚未能够识别任何控制平面服务，这些服务在集群处理积压工作时会耗尽其可用资源，并且集群上的所有其他操作似乎都正常。
我的问题是 - 我应该在哪里寻找系统资源或配置瓶颈？我对 Kubernetes 的了解还不够，无法确切知道哪些组件负责更新 Job 的状态。
在深入研究系统一段时间后，我能够通过调整 kube-controller CLI 标志以允许它使用更多资源来解决此问题。
作为对我原来帖子的更正，我发现新的 Jobs 在创建 Pod 对象时也有延迟。调度程序是响应式的，但它可能需要长达 90 秒才能让 Pod 对象存在才能被调度。控制器负责在创建 Job 时创建 Pod 对象，并在 Pod 完成时更新 Job。
我在这里的标志上找到了文档：https ://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
具体我设置
并且能够处理 1000 个并发作业。