kubernetes的kube-scheduler性能将提升40%

高性能的调度器是一个云平台成功的重要因素之一。在美团云,我们学习Kubernetes的调度思想,实现自己的调度器。去年10月,我加入美团云开始着手优化旧版的调度系统,除了在架构上的优化外,我也不断在思考着如何优化目前调度的流程,kube-scheduler的调度流程有何问题,还有哪些可优化的地方?

一方面我们从调度器的Python实现重构为Go的实现,并增加了一系列的架构优化工作,性能提升了近2个数量级,达到在约30000个节点的集群下每次调度的平均时间低于100ms。这里不是本文的重点,在此略过。

另一方面我们来看看在调度流程上的优化,该优化简单的说是预选阶段的中断机制,我们首先说下调度流程,在此以kubernetes为例子。

我们知道,调度服务是Kubernetes容器集群管理系统中加载并运行的调度程序,负责收集、统计分析容器集群管理系统中所有Node的资源使用情况,然后以此为依据将新建的Pod发送到优先级最高的可用Node上去建立。

调度分为几个部分:

  • 首先是预选过程,过滤掉不满足条件的节点,这个过程称为Predicates
  • 然后是优选过程,对通过的节点按照优先级排序,称之为Priorities
  • 最后是选定过程,从中选择优先级最高的节点,称为Select

我所做的优化就在这里预选阶段这里,预选阶段可以认为是过滤的功能,即遍历全部节点,过滤掉不满足条件的节点,可能会有多个过条件和过滤项,这一阶段输出的所有满足要求的Node都将被记录并作为第二阶段优选过程的输入。

目前在预选阶段即使遇到候选Node不符合某项条件,还是继续判断后面的条件是否符合,但其实对于调度过程来说这部分的计算并不重要,唯一的用途就是可以将目前所有Node的不符合的条件全部记录下来,但这些数据真的很重要吗?尤其是在已经对所有的Predicates排序了的情况下。

这些计算耗时随着条件的增多线性的增长,通过条件失败中断机制在我们目前大约十个条件的情况下性能可以提升40%,每次调度在52ms,甚至更低。

在真实环境中验证之后,我将该优化提交到了Kubernetes官方,优化PR,该优化将随着kubernetes 1.10一起发布!并作为默认设置。大家可以通过策略配置文件的alwaysCheckAllPredicates选项选择false来体验变化。

同行们有兴趣可以在自己的集群下试试是否有提高!

发布于 2018-01-31

文章被以下专栏收录