LWN：Kubernetes scheduler的新功能！

关注了就能看到更多这么棒的文章哦～

New features for the Kubernetes scheduler

December 10, 2019

This article was contributed by Sean Kerner

原文来自：https://lwn.net/Articles/806896/

Kubernetes scheduler正在进行一系列改进，包括引入一套新的框架，增强功能，帮助集群管理员进行性能和利用率的优化。Abdullah Gharaibeh是Kubernetes scheduling special interest group (SIG Scheduling）工作组的联席主席，他在KubeCon + CloudNativeCon North America 2019会议上介绍了scheduler近几个版本的改进，以及后续的路线图。

Kubernetes的scheduler模块是一个把pod分配到节点（node）的控制器。Kubernetes的pod是指一组需要一起调度的容器（container），而node是指集群内部的一台工作机（可以是真实机也可以是虚拟机），它提供了用来运行pod所需的所有服务。

Gharaibeh解释说，pod在创建的时候就会加入调度队列，并按优先级排序，然后经过两个阶段来进行处理。第一个阶段里，pod会经过一些筛选条件，从而决定需要具备什么样功能的node才可以运行这个pod。例如，会检查node是否拥有pod所需的资源（CPU和memory）。第二阶段是打分阶段，此时会对这些pod根据额外一些条件（例如node affinity）来打分。如果出于某些原因，一个pod最后也找不到合适的node来运行，那么就得送回队列之中，等下次条件具备的时候再调度出来。

Scheduling framework

针对scheduler，最近有好几个改进。在Gharaibeh看来，最重要的一个是新的调度框架。这个新框架的目标是把scheduler变成一个执行不同扩展点的callback的引擎。他解释说：“我们希望根据过去使用scheduler的经验，定义一系列扩展点，在这些点上就可以注册callback 函数。可以把一系列用来实现某个特定行为的callback函数称为一个plugin。”

针对调度框架的Kubernetes Enhancement Proposal (KEP)描述列出了所有plugin可用的不同扩展点。其中一个很关键的扩展点名为“queue sort”，在这里可以让管理员定义一个独立的plugin插件来定义如何对这个缺省的调度队列进行排序。这跟目前缺省的方式（按优先级排序）不同。

其他的一些扩展点例子包括“pre-filter”，这里会用来确认某个pod的依赖条件是否满足；还有“filter”，用来把那些不能运行给定pod的node都排除在外；“reserve”扩展点给了那些运行的程序和服务需要维护状态的pod进行优化调度的机会，KEP里面是这么说的：“用来维护运行时状态的插件（stateful plugin）可以利用这个扩展点，在node上pod所需资源已经预留成功的时候，得到scheduler的通知。”

这个框架里还包含了permit plugins，这是用来允许其他调度插件可以延后把pod绑定到node，直到某种特定条件得到满足之后。Gharaibeh认为permit plugin可以用在让需要在同时部署的一批pod一起上线的场景。他说：“我们碰到一类有意思的应用场景就是让批量workload的调度更优化。”

他强调说这个调度框架会让Kubernetes开发者更容易在scheduler中扩展、增加新功能。调度框架目前预计会在2020年中期的Kubernetes 1.19版本中出现。

Oberservability improvements

开发者们还在改善scheduler性能和工作内容的可见性。例如，新增了一个指标，用来记录一个pod从队列中拿出来直到绑定到node上这个pod调度全过程的耗时。还可以统计每秒钟加入进来的pod的数量，这样就能看出scheduler消化调度队列的速度。此外，scheduler还提供了每秒钟试图进行的调度次数。总之，希望给大家展示scheduler内部的更多信息。

Gharaibeh还指出，在Kubernetes 1.17里，在统计pod overhead方面可以拿到更精确的资源使用情况。当pod在某个node上启动的时候，通常都会有一些overhead。在每个node上面运行的kubelet会有一些关于当前运行的这些pod的状态信息，也会消耗集群的一些资源。Sandbox pod，对workload利用gVisor或者Kata Containers这一类技术来进行更好的隔离，它也会需要更好地对资源统计。这些技术都有自己的代理程序，运行在pod之外，都会消耗一些资源但是没有被统计进来。

过去Kubernets处理pod overhead的方式是在node上预留一定量的资源供系统本身模块使用，不过Gharaibeh认为这种做法没有完全包含pod真正消耗的所有overhead。新增的"pod overhead"功能，可以用来定义每个pod需要占用的资源。Kubernetes 1.17里面，schduler就能了解这个pod overhead值，每当pod被调度的时候都会在被占用资源上额外加上这个overhead。

针对Kubernetes 1.18版本，目前在开发一个功能，希望能随时更新pod占用的资源。目前来说，如果要想更改一个pod所占用的资源的话，必须得重新创建这个pod，因为定义了容器消耗资源的PodSpec是无法更改的(immutable)。而Kubernetes 1.18之后，PodSpec针对资源的这部分就可以动态更改(mutable)了。

很难理解scheduler在Kubernetes系统中有多么重要，以及这些改动生效之后对用户有多大影响。新增的框架能够改善扩展性和可定制性，会有助于更高效的利用资源。而对scheduler增加更多对外提供的信息，则有利于Kubernetes系统管理员来说非常有帮助。大家期待后续的发布吧。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～