随着云计算和容器技术的倒退，以docker为外围的容器技术迅速在开发者和科技公司中利用，Kubernetes凭借丰盛的企业级、生产级性能成为事实上的容器集群管理系统。可是k8s的通用性减弱了调度算法的定制性，本文将调研定制化调度算法的办法，并且给出一个开源实现Demo。

k8s与调度器架构

下图1-1是Kubernetes的整体架构图，集群节点分为两种角色：Master节点和Node节点。Master节点是整个集群的管理中心，负责集群治理、容器调度、状态存储等组件都运行在Master节点上；Node节点是实际上的工作节点，负责运行具体的容器。

Kubernetes调度器是独立运行的过程，外部运行过程从逻辑上能够分为多个模块。图1-2展现了默认调度器外部蕴含的具体模块，配置模块负责读取调度器相干配置信息，并且依据配置内容初始化调度器。

• 优先队列模块是一个优先堆数据结构，负责将待调度Pod依据优先级排序，优先级高的Pod排在后面，调度器会轮询优先队列，当队列中存在待调度Pod时就会执行调度过程。
• 调度模块由算法模块、Node缓存和调度扩大点三局部组成，算法模块提供对Node进行评分的一系列根底算法，比方平衡节点CPU和内存使用率的NodeResourcesBalancedAllocation算法，算法模块是可扩大的，用户能够批改和增加本人的调度算法；Node缓存模块负责缓存集群节点的最新状态数据，为调度算法提供数据撑持；调度扩大点由一系列扩大点形成，每个扩大点负责不同的性能，最重要的扩大点是Filter、Score和Bind这三个扩大点。
• 最初是绑定模块，负责将调度器抉择的Node和Pod绑定在一起。

Kubernetes调度器代码采纳可插拔的插件化设计思路，包含外围局部和可插拔局部。图1-2中的配置模块、优先队列和Node缓存是外围局部，算法模块、调度扩大点属于可插拔局部。这种插件化设计容许调度器一些性能通过插件的形式实现，不便代码批改和性能扩大，同时放弃调度器外围代码简略可保护。

下图1-3列出了调度器扩大点模块中蕴含的具体扩大点。Pod的调度过程分为调度周期和绑定周期，调度和绑定周期独特形成Pod的调度上下文。调度上下文由一系列扩大点形成，每个扩大点负责一部分性能，最重要的扩大点是调度周期中的预选(Filter)和优选(Score)扩大点和绑定周期中的绑定(Bind)扩大点。预选扩大点负责判断每个节点是否可能满足Pod的资源需要，不满足就过滤掉该节点。优选扩大点局部会对每个Pod运行默认的评分算法，并且将最终评分加权汇总，失去最初所有节点的综合评分；调度器会抉择综合评分最高的节点，如果有多个节点评分雷同且最高，调度器会通过水塘采样算法在多个节点中随机抉择一个作为调度后果，而后将该节点上Pod申请的资源用量进行保留操作，避免被其它Pod应用。在绑定周期中，调度器将Pod绑定到评分最高的节点上，这一步实质是批改Pod对象中节点相干的信息，并且更新到存储组件etcd中。

定制化算法计划

如果要实现自定义调度算法，次要有三种计划：

1. 批改默认调度器的源代码，退出本人的调度算法，而后从新编译和部署调度器，论文kcss和kubecg中的调度器钻研基于此计划实现；
2. 开发本人的调度器，和默认调度器同时运行在集群中；
3. 基于Kubernetes Scheduler Extender机制，在扩大调度器中实现自定义算法，论文dynamic IO中的算法实现基于这种计划。

上述三种自定义调度算法实现计划的优缺点见表2-1。综合来讲，

• 计划1改变最小，然而这样做会毁坏开源软件的可维护性，当Kubernetes骨干代码更新时，改变后的调度器要和上游代码保持一致，这会带来大量的保护和测试工作。
• 计划2是实现本人的调度器，并且在集群中运行多个调度器，多个调度器之间没有集群资源数据同步，存在并发调度数据竞争和数据不统一的问题。
• 计划3须要默认调度器通过API和Extender交互，新增的网络申请会减少整个调度过程的耗时。

2-1 自研调度算法计划比照

本文的调度器实现采纳计划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是带扩大的默认调度器(kube-scheduler)启动过程，通过kube-policy.json配置文件将扩大调度器Liang的配置信息通知默认调度器。

扩大调度器Liang

扩大调度器Liang独立于Kubernetes默认调度器，Liang的模块设计和组织架构如图3-1所示，包含多维资源采集存储和API服务两大部分。多维资源数据采集通过在集群中运行Prometheus和node-exporter实现，扩大调度器Liang负责从Prometheus获取多维指标而后使用调度算法，将后果返回给默认调度器。

1. api server模块，负责实现合乎扩大调度器数据格式和传输标准的API接口，Liang接管到Kubernetes的评分申请后，解析失去申请中的Pod和候选节点信息，作为参数传递给外部的调度算法，失去候选节点的评分后果并返回给默认调度器。
2. 调度算法模块，扩大调度器Liang的外围模块，负责实现自定义的调度算法。得益于扩大调度器机制，Liang中能够实现多个自定义调度算法。本文次要设计并实现了BNP和CMDN两个调度算法。

3. 数据缓存模块，次要性能有两个：

   1. 通过申请Prometheus的API失去整个Kubernetes集群中所有节点的状态数据。
   2. 实现基于内存的指标数据缓存机制，提供指标数据的写入和读取接口，进步算法运行时获取多维指标数据的速度。

Liang应用Go语言开发，代码量约3400行，开源网址为Liang开源地址。

表3-1是扩大调度器是否应用缓存机制和默认调度器做出调度决策的耗时比照，调度耗时通过在Kubernetes调度器源代码中打印工夫戳的形式获取，别离运行9次而后计算平均值。从表3-1中能够看到，默认调度器做出调度决策的耗时十分小，不到1ms。加上扩大调度器和缓存机制的状况下，均匀调度决策耗时为4.439ms，比默认调度器减少了约3ms，减少的工夫次要是默认调度器与扩大调度器Liang之间网络申请耗时以及Liang运行调度算法所需的工夫。当扩大调度器不加缓存机制时，每次做出调度决策的均匀耗时为1110.439ms，调度耗时迅速减少超过100倍，次要是每次做出调度决策都要申请Prometheus计算和获取集群中的指标数据。因而，扩大调度器加上缓存机制能够防止申请Prometheus带来的网络申请工夫，升高扩大调度器的决策工夫，晋升了扩大调度器的性能。

3-1 不同调度器架构决策耗时

BNP算法

BNP算法在Liang中实现，它将网络IO应用状况纳入k8s调度算法的考量，可能平衡集群中的网络IO用量。

图3-2是试验中默认调度算法和BNP算法中，整个集群中网络IO资源的变动状况，每部署一个Pod统计一次数据，共部署九个Pod。能够显著看到，BNP试验中网络IO资源要比默认调度算法调配更平衡。

CMDN算法

CMDN算法在Liang中实现，它的指标是让集群中的多维资源分配更加平衡或者更加紧凑，外围步骤是针对CPU、内存、磁盘IO和网络IO以及网卡带宽这五个指标进行综合排序，抉择最佳Node部署Pod。图3-3是试验中CPU使用率变动比照状况，能够显著看到，CMDN平衡策略下CPU使用率平衡水平要比默认调度算法调配更平衡。

总结

Kubernetes调度算法的通用性减弱了算法的定制性。本文钻研了k8s调度器架构和扩大机制，比照了三种定制化调度算法计划，抉择扩大计划实现扩大调度器Liang，并在Liang中实现了两个调度算法BNP和CMDN用于展现定制化算法能力。

扩大计划极大丰富了定制化调度算法的能力，能够满足十分多定制化场景的需要。同时也须要留神，定制调度算法往往须要更多的数据，这就须要在k8s集群中额定部署数据采集模块，减少了运维老本，升高了定制化调度算法的通用性。

原文链接，文章继续更新，能够微信搜寻「 机器学习与零碎 」浏览最新内容，回复材料、内推、考研获取相干内容。