我非常快地将2000个短命的作业发送到了我的kube集群，并且观察到在创建作业和启动该作业的Pod之间有几分钟的延迟。有人对瓶颈可能有什么线索吗？
etcd会成为瓶颈吗？
答案 0 :(得分：1)
从10.000英尺的角度看，过程是：
每次安排一个pod /任务时，它都会被添加到队列中。
调度程序读取该队列并将POD分配给节点。
当节点收到Pod的分配时，它通过调用运行时并请求创建来处理创建。
鉴于上述情况，延迟可能是：
ETCD瓶颈也可能是一个问题，但可能性较小，如果是ETCD，您可能会在创建作业时注意到这一点。
此外，值得一提的是，无论节点有多大，在每个节点上 V1.14 no more than 100 pods per node can run at same time 上，每个节点都可以同时运行多少个Pod有一个限制。在这种情况下，您至少需要21个节点才能同时运行所有节点，为请求的Pod需要20个节点，并需要1个额外的节点来解决系统Pod。如果您在云提供商中运行k8，则每个提供商的限制可能会有所不同。
未经调查就很难说问题出在哪里。
总结：
这里有一个工作队列，以确保群集（API / scheduler / ETCD）的可靠性，并防止突发调用影响服务的可用性，在调度Pod之后，节点运行时将下载映像并确保它可以根据需要在自己的时间运行POD。
如果问题是节点中同时运行的Pod的限制，则它可能会减慢速度，因为调度程序在运行另一个节点之前正在等待节点完成Pod，添加更多节点将改善结果
This link详细介绍了k8s调度程序性能问题的一些示例。
This link详细描述了整个流程。