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