随着云计算和容器技术的发展,以docker为核心的容器技术迅速在开发者和科技公司中应用,Kubernetes凭借丰富的企业级、生产级功能成为事实上的容器集群管理系统。可是k8s的通用性
削弱了调度算法的定制性
,本文将调研定制化调度算法的方法,并且给出一个开源实现。
图1-1是Kubernetes的整体架构图,集群节点分为两种角色:Master节点
和Node节点
。Master节点是整个集群的管理中心,负责集群管理、容器调度、状态存储等组件都运行在Master节点上;Node节点是实际上的工作节点,负责运行具体的容器。
图 1-1 Kubernetes整体架构
Kubernetes调度器是独立运行的进程,内部运行过程从逻辑上可以分为多个模块。图1-2展示了默认调度器内部包含的具体模块,配置模块负责读取调度器相关配置信息,并且根据配置内容初始化调度器。
算法模块
、Node缓存
和调度扩展点
三部分组成,算法模块提供对Node进行评分的一系列基础算法,比如均衡节点CPU和内存使用率的NodeResourcesBalancedAllocation算法,算法模块是可扩展的,用户可以修改和添加自己的调度算法;Node缓存模块负责缓存集群节点的最新状态数据,为调度算法提供数据支撑;调度扩展点由一系列扩展点构成,每个扩展点负责不同的功能,最重要的扩展点是Filter、Score和Bind这三个扩展点。图 1-2 Kubernetes调度器架构
Kubernetes调度器代码采用可插拔的插件化设计思路,包括核心部分和可插拔部分。图1-2中的配置模块、优先队列和Node缓存是核心部分,算法模块、调度扩展点属于可插拔部分。这种插件化设计允许调度器一些功能通过插件的方式实现,方便代码修改和功能扩展,同时保持调度器核心代码简单可维护[2]。
图1-3列出了调度器扩展点模块中包含的具体扩展点。Pod的调度过程分为调度周期
和绑定周期
,调度和绑定周期共同构成Pod的调度上下文。调度上下文由一系列扩展点构成,每个扩展点负责一部分功能,最重要的扩展点是调度周期中的预选(Filter)和优选(Score)扩展点和绑定周期中的绑定(Bind)扩展点。
预选扩展点负责判断每个节点是否能够满足Pod的资源需求,不满足就过滤掉该节点。优选扩展点部分会对每个Pod运行默认的评分算法,并且将最终评分加权汇总,得到最后所有节点的综合评分;调度器会选择综合评分最高的节点,如果有多个节点评分相同且最高,调度器会通过水塘采样算法
在多个节点中随机选择一个作为调度结果,然后将该节点上Pod申请的资源用量进行保留操作,防止被其它Pod使用。在绑定周期中,调度器将Pod绑定到评分最高的节点上,这一步本质是修改Pod对象中节点相关的信息,并且更新到存储组件etcd中。
图 1-3 Kubernetes调度器扩展点架构
如果要实现自定义调度算法,主要有三种方案:
上述三种自定义调度算法实现方案的优缺点见表2-1。综合来讲,
表2-1 自研调度算法方案对比
方案 | 优点 | 缺点 |
---|---|---|
方案1:修改调度器源代码 | 改动小 | 破坏源代码、不好维护 |
方案2:运行多个调度器 | 不改动源代码 | 存在数据竞争、不一致 |
方案3:开发扩展调度器 | 不改动源代码 | 存在网络耗时 |
本文的调度器实现采用方案3,设计并开发符合Scheduler Extender机制和API规范的扩展调度器,将其命名为Liang。代码2-1是扩展调度器JOSN格式的策略配置文件,通过配置文件参数将该策略文件传递给Kubernetes默认调度器,其中urlPrefix表示扩展调度器Liang运行后监听的API地址,prioritizeVerb表示优选扩展点在扩展调度器中的路由。当默认调度器在优选扩展点运行完评分插件后会发送HTTP POST网络请求到Liang的API地址,并将Pod和候选节点信息放在HTTP Body中一起传递过去。接收到POST请求后,扩展调度器Liang会根据评分算法对节点进行评分并将结果返回给默认调度器。
{
"kind": "Policy",
"apiVersion": "v1",
"extenders": [
{
"urlPrefix": "http://localhost:8000/v1",
"prioritizeVerb": "prioritizeVerb",
"weight": 1,
"enableHttps": false,
"httpTimeout": 1000000000,
"nodeCacheCapable": true,
"ignorable": false
}
]
}
代码 2-1
图2-1是带扩展的默认调度器(kube-scheduler)启动过程,通过kube-policy.json配置文件将扩展调度器Liang的配置信息告诉默认调度器。
图 2-1 扩展调度器通过配置文件传递给默认调度器启动
扩展调度器Liang独立于Kubernetes默认调度器,Liang的模块设计和组织架构如图3-1所示,包括多维资源采集存储和API服务两大部分。多维资源数据采集通过在集群中运行Prometheus和node-exporter实现,扩展调度器Liang负责从Prometheus获取多维指标然后运用调度算法,将结果返回给默认调度器。
图 3-1 扩展调度器Liang整体架构
Liang使用Go语言开发,代码量约3400行,开源网址为Liang开源地址[7]。
表3-1是扩展调度器是否使用缓存机制和默认调度器做出调度决策的耗时对比,调度耗时通过在Kubernetes调度器源代码中打印时间戳的方式获取,分别运行9次然后计算平均值。从表3-1中可以看到,默认调度器做出调度决策的耗时非常小,不到1ms。加上扩展调度器和缓存机制的情况下,平均调度决策耗时为4.439ms,比默认调度器增加了约3ms,增加的时间主要是默认调度器与扩展调度器Liang之间网络请求耗时以及Liang运行调度算法所需的时间。
当扩展调度器不加缓存机制时,每次做出调度决策的平均耗时为1110.439ms,调度耗时迅速增加超过100倍,主要是每次做出调度决策都要请求Prometheus计算和获取集群中的指标数据。因此,扩展调度器加上缓存机制可以避免请求Prometheus带来的网络请求时间,降低扩展调度器的决策时间,提升了扩展调度器的性能。
表 3-1 不同调度器架构决策耗时
调度类型 | 平均决策耗时 |
---|---|
默认调度器 | 0.945ms |
扩展调度器-使用缓存 | 4.439ms |
扩展调度器-不使用缓存 | 1110.439ms |
BNP算法在Liang中实现,它将网络IO使用情况纳入k8s调度算法的考量,能够均衡集群中的网络IO用量。
图3-2是实验中默认调度算法和BNP算法中,整个集群中网络IO资源的变化情况,每部署一个Pod统计一次数据,共部署九个Pod。可以明显看到,BNP实验中网络IO资源要比默认调度算法分配更均衡。
图 3-2 bnp算法网络IO使用率变化情况
CMDN算法在Liang中实现,它的目标是让集群中的多维资源分配更加均衡或者更加紧凑,核心步骤是针对CPU、内存、磁盘IO和网络IO以及网卡带宽这五个指标进行综合排序,选择最佳Node部署Pod。图3-3是实验中CPU使用率变化对比情况,可以明显看到,CMDN均衡策略下CPU使用率均衡程度要比默认调度算法分配更均衡。
图 3-3 cmdn算法均衡策略下CPU使用率变化情况
Kubernetes调度算法的通用性削弱了算法的定制性。本文研究了k8s调度器架构和扩展机制,对比了三种定制化调度算法方案,选择扩展方案实现扩展调度器Liang
,并在Liang中实现了两个调度算法BNP和CMDN用于展示定制化算法能力。
扩展方案极大丰富了定制化调度算法的能力,可以满足非常多定制化场景的需求。同时也需要注意,定制调度算法往往需要更多的数据,这就需要在k8s集群中额外部署数据采集模块,增加了运维成本,降低了定制化调度算法的通用性。
[1]当队列中存在待调度Pod时就会执行调度过程: http://dx.doi.org/10.24138/jcomss.v16i1.1027
[2]同时保持调度器核心代码简单可维护: https://v1-20.docs.kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/
[3]kcss: https://doi.org/10.1007/s11227-020-03427-3
[4]kubecg: https://doi.org/10.1002/spe.2898
[5]Kubernetes Scheduler Extender机制: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md
[6]dynamic IO: https://doi.org/10.1145/3407947.3407950
[7]Liang开源地址: https://github.com/adolphlwq/liang