CN115550371B - 基于Kubernetes的Pod调度方法、系统及云平台 - Google Patents

Abstract

本发明提供了基于Kubernetes的Pod调度方法、系统及云平台，该Pod调度方法包括：在创建Pod请求时添加剩余可用带宽配置值；确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；监测Pod请求，通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与剩余可用带宽配置值，以过滤出符合Pod请求的工作节点；向符合Pod请求的工作节点所属的守护进程组件予以响应，以将Pod请求绑定至工作节点。本申请实现了在首调度阶段中能够被合理且准确地被调度至Pod请求的工作节点中，以避免发生重调度事件。

Description

基于Kubernetes的Pod调度方法、系统及云平台

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于Kubernetes的Pod调度方法、系统及云平台。

背景技术

Kubernetes为开源的容器集群管理系统，用于自动部署、扩展和管理容器化（containerized）应用程序，并形成分布式主从架构。参图1与图2所示，Kubernetes包括一个主节点（Master node）10，以及被主节点10所纳管的一个或者多个工作节点（Work node）21。响应用户请求的业务通过Pod予以承载并响应用户请求，Pod在被创建时会被调度至具体的工作节点（node），Pod封装体现业务逻辑的应用程序的一个或者多个容器（Container），工作节点21中可部署n个Pod。主节点10部署资源访问组件（kube-apiserver）13，运行管理控制器组件（kube-controller-manager）11，调度器（kube-scheduler）12及与ETCD组件14；每个工作节点21部署守护进程组件（kubelet）15及执行组件（kube-proxy）16。调度器12接收用户发起的创建Pod请求时，根据工作节点的资源情况及容器所需资源（例如，带宽资源）作出具体的调度策略，以确定运行该Pod所对应的工作节点。

用户在客户端50分别通过网卡211、网卡221及网卡231连分别连接工作节点21、工作节点22及工作节点23。远端服务60通过网卡211~231连接一个或者多个工作节点。然而，对于存在网络转发需求的用户请求及应用程序场景中，对待部署Pod所在的工作节点的剩余可用带宽而言就显得尤其重要，剩余可用带宽对确保服务质量（QoS）具有重要影响。申请人检索后指出公开号为CN111694636A、CN114911613A等现有技术仅仅揭示了对Pod基于节点负载或者节点所配置的网卡流量或者带宽进行实时检测，以确定是否对Pod调度至其他工作节点的技术方案。然而，现有技术并未揭示如何在Pod被创建及部署的首调度阶段中就能够被合理且准确地被调度至符合Pod所承载的应用程序的工作节点中，从而导致Pod被创建及部署后即可能面临需要被重新调度至其他工作节点的风险及可能性。而对Pod调度至其他工作节点不仅需要消耗计算资源，还对工作节点之间的带宽资源造成了一定开销。

有鉴于此，有必要对现有技术中的基于Kubernetes的Pod调度方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示基于Kubernetes的Pod调度方法、系统及云平台，用以实现在Pod在首调度过程中能够被调度至具有足以承载应用程序所需带宽资源的工作节点中，避免Pod请求所对应的Pod被调度至当前剩余可用带宽不足的工作节点所引发的重调度事件。

为实现上述目的之一，本发明提供了一种基于Kubernetes的Pod调度方法，包括：

在创建Pod请求时添加剩余可用带宽配置值；

确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

监测所述Pod请求，通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点；

向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以将所述Pod请求绑定至所述工作节点。

作为本发明的进一步改进，所述剩余可用带宽配置值以对象资源配置文件的形式注入资源访问组件，并将所述对象资源配置文件添加至Pod的注解中，所述对象资源配置文件包括基础剩余可用带宽值和/或期望剩余可用带宽值，其中，所述期望剩余可用带宽值大于所述基础剩余可用带宽值。

作为本发明的进一步改进，所述对象资源配置文件包括基础剩余可用带宽值与期望剩余可用带宽值，且所述基础剩余可用带宽值与期望剩余可用带宽值形成唯一的绑定关系；

在周期性地以心跳信息形式上报至资源访问组件后，所述Pod调度方法还包括：更新工作节点的当前剩余可用带宽。

作为本发明的进一步改进，所述当前剩余可用带宽周期性地以心跳信息形式上报至资源访问组件后，被写入至ETCD组件；

所述剩余可用带宽调度器自所述ETCD组件获取各个工作节点的当前剩余可用带宽，以对各个工作节点执行遍历查询，移除当前剩余可用带宽小于基础剩余可用带宽值所对应的工作节点，并将当前剩余可用带宽大于或者等于基础剩余可用带宽值的工作节点中根据剩余可用带宽得分最高的工作节点作为响应所述Pod请求的工作节点，其中，响应所述Pod请求的工作节点在被确定之前，由所述剩余可用带宽调度器在响应所述Pod请求的工作节点予以提前确定。

作为本发明的进一步改进，所述剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的绝对值确定，其中，绝对值越小，所述工作节点所对应的剩余可用带宽得分越高，所述绝对值小于或者等于所述期望剩余可用带宽值与所述基础剩余可用带宽值之间所形成的差值。

作为本发明的进一步改进，所述剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的正差值确定，其中，正差值越大，所述工作节点所对应的剩余可用带宽得分越高。

作为本发明的进一步改进，所述工作节点独立部署一连接守护进程组件的剩余可用带宽检查器，所述剩余可用带宽调度器连接调度器，所述调度器连接资源访问组件，以在所述资源访问组件中根据对工作节点所采集到的当前剩余可用带宽，以根据注入资源访问组件的对象资源配置文件所包含的基础剩余可用带宽值与期望剩余可用带宽值为条件，筛选出至少一个当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点；所述剩余可用带宽检查器监测工作节点的网卡，以确定工作节点的当前剩余可用带宽。

作为本发明的进一步改进，所述Pod调度方法还包括：将筛选出的当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点作为被过滤出的符合所述Pod请求的工作节点，并作为可调度工作节点池，并在接收到下一个Pod请求时，根据对象资源配置文件从可调度工作节点池中选取一个剩余可用带宽得分最高的工作节点作为响应下一个Pod请求的工作节点，其中，所述对象资源配置文件包括Yaml文件、JSON文件或者命令行。

其次，基于相同发明思想，本发明提供了基于Kubernetes的Pod调度系统，包括：

部署于主节点中的调度器、资源访问组件及剩余可用带宽调度器，部署于被主节点所纳管的若干工作节点中的守护进程组件及剩余可用带宽检查器；

在创建Pod请求时向所述资源访问组件添加剩余可用带宽配置值；

剩余可用带宽检查器确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

由所述调度器监测所述资源访问组件获取的Pod请求，并通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点；

由所述资源访问组件向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以通过所述资源访问组件将所述Pod请求绑定至所述工作节点。

最后，基于相同发明思想，本发明提供了一种云平台，包括：

主节点，以及若干被所述主节点所纳管的工作节点，

所述主节点部署资源访问组件及连接所述资源访问组件的运行管理控制器组件、调度器及ETCD组件，所述调度器连接剩余可用带宽调度器；所述工作节点部署守护进程组件、执行组件及剩余可用带宽检查器；

在创建Pod请求时向所述资源访问组件添加剩余可用带宽配置值；

剩余可用带宽检查器确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

由所述调度器监测所述资源访问组件获取的Pod请求，并通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点；

由所述资源访问组件向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以通过所述资源访问组件将所述Pod请求绑定至所述工作节点。

与现有技术相比，本发明的有益效果是：

在本申请中，通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与剩余可用带宽配置值，以过滤出符合Pod请求的工作节点，在接收到用户发起的Pod请求时，在首调度阶段中能够被合理且准确地被调度至符合Pod所承载的应用程序的工作节点中，以有效地避免发生重调度事件。

附图说明

图1为现有技术中Kubernetes整体架构图；

图2为部署Pod的多个工作节点响应客户端示意图；

图3为本发明基于Kubernetes的Pod调度方法的整体流程图；

图4为运行图3所示出的本发明基于Kubernetes的Pod调度方法的Kubernetes集群整体架构图，为省略表示，Kubernetes集群仅示出一个工作节点；

图5为向图4中的资源管理组件注入的对象资源配置文件的示意图；

图6为本发明基于Kubernetes的Pod调度方法的时序图；

图7为剩余可用带宽调度器基于过滤逻辑对多个工作节点进行过滤后，以过滤出能够响应用户业务的Pod调度至满足业务所需带宽的工作节点的示意图；

图8为将Pod请求调度至当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点的示意图；

图9为将Pod请求调度至当前剩余可用带宽与期望剩余可用带宽值之间形成正差值的工作节点的示意图；

图10为在一种变形例中将过滤器部署于资源访问组件的示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

简要而言，本申请所揭示的一种基于Kubernetes的Pod调度方法（以下简称“Pod调度方法”或者“方法”）及基于Kubernetes的Pod调度方法（以下简称“Pod调度系统”）及云平台旨在实现对基于Kubernetes的云平台或者计算机集群场景中，对用户发起业务请求予以响应，并在首调度阶段（或称“首次调度阶段”）时，确保被调度以响应Pod请求的工作节点形成的当前剩余可用带宽能够满足Pod所承载应用程序所需带宽资源。目前，现有的对Pod请求所对应的Pod调度至工作节点的技术方案，旨在追求各个工作节点间的资源实现动态平衡，或者，在各个工作节点中所形成的资源（例如，带宽资源、存储资源、CPU资源、内存资源等）进行综合计算资源得分。然而，这对于诸如部署Web服务器等对剩余可用带宽要求非常苛刻的Pod请求而言，则存在调度策略无法满足Pod调度所需工作节点的缺陷，并存在对Pod请求的任务执行解析及调度过程繁琐等技术缺陷。因此，本申请所揭示的Pod调度方法、Pod调度系统及云平台旨在接收到用户在诸如图2所示出的客户端50所发起的Pod请求调度至合理的工作节点，以将应用程序落地并予以可靠执行。客户端50可为用户端（例如，嵌布UI的计算机终端设备）或者业务前端（例如，Web前端）等，以防止在首调度后尽量避免发生二次调度（即，重调度），从而避免因Pod执行二次调度在工作节点间迁移所消耗的带宽资源及计算资源。

参图3及图4所示，该Pod调度方法包括步骤S1至步骤S4。

步骤S1、在创建Pod请求时添加剩余可用带宽配置值。

剩余可用带宽配置值以对象资源配置文件19的形式注入资源访问组件13，并将对象资源配置文件19添加至Pod的注解（即，annotations）中，对象资源配置文件19包括基础剩余可用带宽值和/或期望剩余可用带宽值，其中，期望剩余可用带宽值大于基础剩余可用带宽值。同时，对象资源配置文件19包括Yaml文件19a、JSON文件或者命令行。参图6所示，本实施例示出了Yaml文件19a的一种具体实例，该Yaml文件19a包含apiVersion（即，Kubernetes的接口版本）、Kind（即，功能）、annotations（即，注解）及其他设置值（即，spec）。annotations包含基础剩余可用带宽值（即，requiredRBW）与期望剩余可用带宽值（即，expectedRBW）；示例性地，在本实施例中，基础剩余可用带宽值被配置为100MB/S，期望剩余可用带宽值被配置为500 MB/S。

对象资源配置文件19包括基础剩余可用带宽值与期望剩余可用带宽值，且基础剩余可用带宽值与期望剩余可用带宽值形成唯一的绑定关系。同时，在周期性地以心跳信息形式上报至资源访问组件13后，Pod调度方法还包括：更新工作节点的当前剩余可用带宽。基础剩余可用带宽值与期望剩余可用带宽值形成唯一的绑定关系，并被整体封装在对象资源配置文件19中。参图5所示，用户通过客户端50向资源访问组件13发起Pod请求时，将对象资源配置文件19注入资源访问组件13，并执行后续图5中的步骤404~步骤413。当Pod请求被确定出某个具体的工作节点后，对象资源配置文件19失效，并开始接收并响应下一个Pod请求，并确定在下一个首调度过程中确定匹配的一个工作节点，或者，从可调度工作节点池中根据对象资源配置文件19从可调度工作节点池中选取一个剩余可用带宽得分最高的工作节点作为响应下一个Pod请求的工作节点。

步骤S2、确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件13。

当前剩余可用带宽周期性地以心跳信息形式上报至资源访问组件13后，被写入至ETCD组件14。剩余可用带宽调度器18自ETCD组件14获取各个工作节点的当前剩余可用带宽，以对各个工作节点执行遍历查询，移除当前剩余可用带宽小于基础剩余可用带宽值所对应的工作节点，并将当前剩余可用带宽大于或者等于基础剩余可用带宽值的工作节点中根据剩余可用带宽得分最高的工作节点作为响应Pod请求的工作节点，其中，响应Pod请求的工作节点在被确定之前，由剩余可用带宽调度器18在响应Pod请求的工作节点予以提前确定。被纳入可调度工作节点池的工作节点在当前状态中的剩余可用带宽必须大于或者等于基础剩余可用带宽值。剩余可用带宽调度器18可以插件并以边车模式（Sidecar）予以部署，以提高剩余可用带宽调度器18部署过程的灵活性及可扩展性，从而可根据Kubernetes集群中所含工作节点的数量、部署架构及整体带宽，修改剩余可用带宽调度器18对工作节点的调度逻辑与过滤逻辑，进一步提高了对工作节点执行首调度过程的细腻度。

步骤S3、监测所述Pod请求，通过部署于主节点10中的剩余可用带宽调度器18获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点。

具体而言，过滤出符合Pod请求的工作节点的过滤逻辑由剩余可用带宽调度器18中所部署的由计算机代码所构建的过滤器32予以实现。作为前述实施例的合理变形，参图10所示，还可将过滤器32部署于资源访问组件13中，并优选为将过滤器32部署于剩余可用带宽调度器18中。过滤器32根据本次Pod请求所注入的对象资源配置文件19，从Node-1~Node-m中，参数m选自大于或者等于1的正整数，基于对象资源配置文件19过滤出至少一个符合本次Pod请求的工作节点，并从Node-1~Node-m过滤出的工作节点中的Pod执行remote操作，将某个工作节点（例如，Node-x）复制到本地系统，从而将承载Pod请求的业务逻辑的服务（即，Service31）部署至被选定的某个工作节点，以形成本地系统的本地Pod（即，LocalPod33），从而运行服务31。过滤器32可基于类过滤器（即，Implements Filter）予以实现。

工作节点独立部署一连接守护进程组件15的剩余可用带宽检查器17，剩余可用带宽调度器18连接调度器12，调度器12连接资源访问组件13，以在资源访问组件13中根据对工作节点所采集到的当前剩余可用带宽，以根据注入资源访问组件13的对象资源配置文件19所包含的基础剩余可用带宽值与期望剩余可用带宽值为条件，筛选出至少一个当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点；剩余可用带宽检查器17监测工作节点的网卡171，以确定工作节点在当前状态中所形成的当前剩余可用带宽，然后才执行响应本次Pod请求的首调度事件。剩余可用带宽检查器17基于Linux网络工具（例如，ifconfig、iftop、ethtool）查询网卡171，以确定首调度事件中对应工作节点在当前状态中所具有的剩余可用带宽，而工作节点的总带宽可被提前获知，且总带宽相对固定不变。资源访问组件13接收到用户发起的Pod请求时，由调度器12调用并启用剩余可用带宽调度器18，并由部署于主节点10的剩余可用带宽调度器18对各个工作节点进行过滤与剩余可用带宽打分。

同时，Kubernetes集群中的每个工作节点均部署一个剩余可用带宽检查器17，通过监测剩余可用带宽检查器17所属的工作节点的网卡171的流量，以确定在本次首调度执行过程中的当前剩余可用带宽。同时，对网卡171的流量进行监测包括对网卡的171的出口流量或者入口流量或者同时包含出口流量与入口流量的整体流量进行检测，且可根据本次Pod请求所对应的服务31的不同类型予以调整。不同类型的服务31对数据报文所要求的流向是不同的，对于某些对出口流量要求高的服务，只要检测出口流量即可，而无需关心入口流量。当剩余可用带宽检查器17检测到网卡171的流量后，将当前状态的流量发送至守护进程组件15，并最终通过工作节点21的守护进程组件15将前述当前状态的流量反馈至主节点10的资源访问组件13，以被剩余可用带宽调度器18所获取，并执行图5中的步骤405~步骤413。

步骤S4、向符合所述Pod请求的工作节点所属的守护进程组件15予以响应，以将所述Pod请求绑定至所述工作节点。结合图5所示，步骤412：Node-x所属的守护进程组件15（即，kubelet）watch到Pod，并将Pod请求所对应的Pod绑定到Node-x，以最后执行步骤413：创建并运行Pod。前述Node-x中的x为图7中的Node-1~Node-m中的任意一个工作节点。步骤S4执行完毕后，执行组件16（即，kube-proxy）通过观察Kubernetes集群中服务和endpoint对象的变化，当有新的服务（例如，Service31）被创建时，由被选定的工作节点Node-x中所部署的kube-proxy在工作节点Node-x上随机选择一个端口，在iptables（即，IP 信息包过滤系统）中追加一条把访问服务的请求重定向到这个端口的记录，并开始监听这个端口的连接请求。鉴于本申请并非对执行组件16所作出的改进，故，在本实施例中不予以展开详细阐述，并可采用现有技术中的kube-proxy予以执行。

参图7所示，该Pod调度方法还包括：将筛选出的当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点作为被过滤出的符合Pod请求的工作节点，并作为可调度工作节点池，并在接收到下一个Pod请求时，根据对象资源配置文件19从可调度工作节点池中选取一个剩余可用带宽得分最高的工作节点作为响应下一个Pod请求的工作节点。由此，使得本申请所揭示的Pod调度方法能够进一步缩小确定响应下一个Pod请求的工作节点的确定范围，从而进一步提高Pod请求所对应的Pod能够被合理且准确地被调度至符合Pod所承载的应用程序（例如，Service31）的工作节点，以进一步降低了工作节点的执行首调度过程的计算开销。可调度工作节点池可保存于ETCD组件14中。

参图5所示，当存在可调度工作节点时，执行步骤408：对可调度工作节点的带宽得分（即，拟被确定为响应Pod请求所对应的工作节点在本次Loop过程中仅针对剩余可用带宽的得分），此时可能被过滤器32过滤出的工作节点可能不止一个，因此需要进一步地执行步骤409及步骤410，从而选举出一个综合得分最好的工作节点Node-x最为最终响应Pod请求的工作节点。步骤409：继续对其他工作节点的调度流程。步骤409中的调度流程区别于前述剩余可用带宽得分最高的工作节点的筛选过程，且具体为对工作节点在当前节点所具有的剩余存储得分、剩余图形运算得分、剩余浮点计算得分、剩余内存得分中的一种得分或者几种得分之和最高为依据，以执行步骤410：结合所有调度流程（即，对剩余存储、剩余图形运算等进行调度）的得分，以选择出得分最高的工作节点Node-x作为最终被选定的工作节点，以响应本次Pod请求所对应的Pod的运行需求。

Kubernetes集群所包含的多个工作节点在前一次首调度执行完毕后，会将所有节点在当前状态中所形成的剩余可用带宽以心跳信息上报至ETCD组件14，并对ETCD组件14所保存的各个工作节点在上一次心跳检测周期所形成的剩余可用带宽执行更新。主节点10中的资源访问组件13能够在下一次响应某个Pod请求阶段中，从ETCD组件14中调用全部工作节点所形成的当前状态下的剩余可用带宽。计算剩余可用带宽得分仅在一个Loop周期中通过轮询全部工作节点的方式予以确定，且后续执行的步骤409与步骤410也在同一个Loop周期中执行。同时，需要说明的是，步骤409与步骤410也予以省略，并在步骤408结束后依次执行步骤411、步骤412及步骤413。因此，本实施例所揭示的Pod调度方法相对于现有技术中采用蚁群系统（Ant Colony System，ACS）算法而言，能够克服现有技术响应Pod请求并将Pod调度至某个具体的工作节点过程中存在算法复杂的缺陷，并尤其地，本申请所揭示的Pod调度方法能够显著地降低将Pod调度至具体的工作节点中所存在的随机性与异步性，从而确保被选定的工作节点足以满足Pod及服务31在工作节点上的可靠运行，从而有效地避免了Pod请求所对应的Pod被调度至当前剩余可用带宽不足的工作节点所引发的重调度事件。

同时，在本申请所揭示的Pod调度方法中，能够有效地满足并有效响应诸如Web服务器等对剩余可用带宽要求非常苛刻的Pod请求。又或者，相对于现有技术中在各个工作节点中部署SDN控制器（未示出），以基于SDN控制器周期性地侦测网络拓扑和链路状态信息，以基于ECMP算法或者WCMP算法等多路径路由算法而言，则会因为带宽、时延和可靠性等不同而导致报文转发出现乱序。例如，假设路由器两个出口，由此形成两条报文转发路径，一个工作节点的带宽是100M/S，另一个工作节点的带宽是2M/S，如果采用ECMP算法部署，则网络总带宽只能达到4M/S，显然这并不适合本申请Kubernetes集群中对Pod请求的调度操作。同时，如果基于ECMP算法需要在各个工作节点中的交换机安装对应流表项，从而增加了部署及维护成本，运维人员需要设置流表项。显然，本申请所揭示的Pod调度方法并不存在上述技术问题，且能够充分利用各个工作节点在当前状态中的剩余可用带宽，具有部署及维护简单的优点，并尤其地具有算法简单，工作节点调度准确的优点。

示例性地，参图8所示，剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的绝对值确定，其中，绝对值越小，工作节点所对应的剩余可用带宽得分越高，且绝对值小于或者期望剩余可用带宽值与基础剩余可用带宽值之间所形成的差值。例如，当接收到的Pod请求中的对象资源配置文件19所包含的基础剩余可用带宽值被配置为400MB/S，期望剩余可用带宽值被配置为500 MB/S。此时图8中的工作节点-1在当前状态中的总带宽1500 MB/S，且已使用带宽为600MB/S，当前剩余可用带宽为900 MB/S。工作节点-2在当前状态中的总带宽也为1500 MB/S，且已使用带宽为1000MB/S，当前剩余可用带宽为500 MB/S。此时，对于工作节点-2而言，其所形成的当前剩余可用带宽（即，500 MB/S）与期望剩余可用带宽值（即，500 MB/S）之间形成的绝对值为0 MB/S。对于工作节点-1而言，其所形成的当前剩余可用带宽（即，900 MB/S）与期望剩余可用带宽值（即，500 MB/S）之间形成的绝对值为400 MB/S。由此可见，将工作节点-2作为可调度工作节点是合理的，并可避免将工作节点-1调度给Pod请求所导致的带宽浪费。因此，在图8所示出的调度场景中，图8中的Pod请求的Pod沿图8中箭头所示出的方向被调度至工作节点-2。

又或者，参图9所示，剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的正差值确定，其中，正差值越大，工作节点所对应的剩余可用带宽得分越高。对于工作节点-1而言，在当前状态中的总带宽1500 MB/S，且已使用带宽为600MB/S，当前剩余可用带宽为900 MB/S，其所形成的当前剩余可用带宽（即，900 MB/S）与期望剩余可用带宽值（即，500 MB/S）之间形成的绝对值为400 MB/S。对于工作节点-2而言，在当前状态中的总带宽1500 MB/S，且已使用带宽为1000MB/S，当前剩余可用带宽为500MB/S，其所形成的当前剩余可用带宽（即，500 MB/S）与期望剩余可用带宽值（即，500 MB/S）之间形成的绝对值为0 MB/S。对于工作节点-3而言，在当前状态中的总带宽1500 MB/S，且已使用带宽为800MB/S，其所形成的当前剩余可用带宽（即，700 MB/S）与期望剩余可用带宽值（即，500 MB/S）之间形成的绝对值为200 MB/S。因此，图9中的Pod请求的Pod沿图9中箭头所示出的方向，可被调度至工作节点-1或者工作节点-3，且可将工作节点-1与工作节点-3纳入可调度工作节点池。

可见，本申请所揭示的Pod调度方法能够在首调度阶段中被合理且准确地被调度至符合Pod所承载的应用程序的工作节点中，以有效地避免发生重调度事件。

更具体地，申请人结合图5对该Pod调度方法具体执行步骤予以进一步阐述。

步骤401：在前一个首调度执行完毕后，各个工作节点所部署的守护进程组件15按照心跳信息的采集周期，定时发送携带本工作节点剩余可用带宽信息的心跳信息至资源访问组件13。

步骤402：主节点10中的资源访问组件13基于心跳信息的检测周期，周期性地更新各个工作节点的剩余可用带宽信息。

步骤403：用户在客户端50中创建带有剩余可用带宽需求的Pod负载，并向资源访问组件13注入对象资源配置文件19。

步骤404：调度器12监测获取Pod请求。

步骤405：调度器12调用剩余可用带宽调度器18对各工作节点进行过滤和打分。

步骤406：查询当前状态中各个工作节点所形成的剩余可用带宽，并在存在剩余可用带宽时，跳转执行步骤407的判断逻辑。若某个工作节点的总带宽已经全部被占用，即，无剩余可用带宽，则表示该工作节点不能被作为最终响应Pod请求的工作节点，并返回Pod调度失败，并由资源访问组件13向用户予以响应。

步骤407：由剩余可用带宽调度器18判断是否存在可调度工作节点，并基于前文所揭示的技术方案过滤获取符合Pod请求的一个或者多个工作节点。若是，跳转执行步骤408；若否，依然返回Pod调度失败。

步骤408：对可调度工作节点的得分（即，剩余可用带宽得分）进行打分。

步骤409：继续进行对其他工作节点的调度流程。

步骤410：综合所有调度流程的得分，选择得分最好的工作节点Node-x，响应该Pod请求。

步骤411：绑定Node-x到Pod。

步骤412：最终被选定的工作节点Node-x所属的守护进程组件15（即，kubelet）watch到Pod，并将Pod请求所对应的Pod绑定到Node-x。

步骤413：创建并运行Pod。

步骤414：由剩余可用带宽检查器17按照心跳信息的定时周期，定时调用剩余可用带宽检查器17检测并计算本计算节点的剩余可用带宽。步骤414在每一个Loop周期的执行前与执行后依次执行。

至此，Pod调度方法所含步骤全部执行完毕，且可基于该Pod调度方法应用于下文所揭示的基于Kubernetes的Pod调度系统及云平台中。

基于前述具体实施方式所揭示的一种基于Kubernetes的Pod调度方法，本申请还揭示了一种基于Kubernetes的Pod调度系统（以下简称“Pod调度系统”）。具体而言，Pod调度系统包括：部署于主节点10中的调度器12、资源访问组件13及剩余可用带宽调度器18，部署于被主节点10所纳管的若干工作节点（即，图7中的Node-1~Node-m，或者图9中的工作节点-1~工作节点-3）中的守护进程组件15及剩余可用带宽检查器17。

在创建Pod请求时向资源访问组件13添加剩余可用带宽配置值。剩余可用带宽检查器17确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件13。由调度器12监测资源访问组件13获取的Pod请求，并通过部署于主节点10中的剩余可用带宽调度器18获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与剩余可用带宽配置值，以过滤出符合Pod请求的工作节点。由资源访问组件13向符合Pod请求的工作节点所属的守护进程组件15予以响应，以通过资源访问组件13将Pod请求绑定至工作节点。

Pod调度系统与前述实施例所揭示的Pod调度方法中含有相同部分的技术方案，参前所述，在此不再赘述。

基于前述具体实施方式所揭示的一种基于Kubernetes的Pod调度方法及基于Kubernetes的Pod调度系统，本申请还揭示了一种云平台，包括：主节点，以及若干被主节点10所纳管的工作节点21，工作节点21通常包括多个，例如，图9中的工作节点-1~工作节点-3，又例如，图7中的Node-1~Node-m。图7中的Node-1~Node-m以及图9中的工作节点-1~工作节点-3均为工作节点21的下位概念。

主节点10部署资源访问组件13及连接资源访问组件13的运行管理控制器组件11、调度器12及ETCD组件14，调度器12连接剩余可用带宽调度器18。工作节点部署守护进程组件15、执行组件16及剩余可用带宽检查器17。在创建Pod请求时向资源访问组件13添加剩余可用带宽配置值。剩余可用带宽检查器17确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件13。由调度器12监测资源访问组件13获取的Pod请求，并通过部署于主节点10中的剩余可用带宽调度器18获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与剩余可用带宽配置值，以过滤出符合Pod请求的工作节点。由资源访问组件13向符合Pod请求的工作节点所属的守护进程组件15予以响应，以通过资源访问组件13将Pod请求绑定至工作节点。

云平台与前述实施例所揭示的Pod调度系统中含有相同部分的技术方案，参前所述，在此不再赘述。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.一种基于Kubernetes的Pod调度方法，其特征在于，包括：

在创建Pod请求时添加剩余可用带宽配置值；

确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

监测所述Pod请求，通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点，所述剩余可用带宽配置值以对象资源配置文件的形式注入资源访问组件；

向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以将所述Pod请求在首调度阶段中绑定至所述工作节点。

2.根据权利要求1所述的基于Kubernetes的Pod调度方法，其特征在于，还包括：将所述对象资源配置文件添加至Pod的注解中，所述对象资源配置文件包括基础剩余可用带宽值和/或期望剩余可用带宽值，其中，所述期望剩余可用带宽值大于所述基础剩余可用带宽值。

3.根据权利要求2所述的基于Kubernetes的Pod调度方法，其特征在于，所述对象资源配置文件包括基础剩余可用带宽值与期望剩余可用带宽值，且所述基础剩余可用带宽值与期望剩余可用带宽值形成唯一的绑定关系；

在周期性地以心跳信息形式上报至资源访问组件后，所述Pod调度方法还包括：更新工作节点的当前剩余可用带宽。

4.根据权利要求1所述的基于Kubernetes的Pod调度方法，其特征在于，所述当前剩余可用带宽周期性地以心跳信息形式上报至资源访问组件后，被写入至ETCD组件；

所述剩余可用带宽调度器自所述ETCD组件获取各个工作节点的当前剩余可用带宽，以对各个工作节点执行遍历查询，移除当前剩余可用带宽小于基础剩余可用带宽值所对应的工作节点，并将当前剩余可用带宽大于或者等于基础剩余可用带宽值的工作节点中根据剩余可用带宽得分最高的工作节点作为响应所述Pod请求的工作节点，其中，响应所述Pod请求的工作节点在被确定之前，由所述剩余可用带宽调度器在响应所述Pod请求的工作节点予以提前确定。

5.根据权利要求4所述的基于Kubernetes的Pod调度方法，其特征在于，所述剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的绝对值确定，其中，绝对值越小，所述工作节点所对应的剩余可用带宽得分越高，所述绝对值小于或者等于所述期望剩余可用带宽值与所述基础剩余可用带宽值之间所形成的差值。

6.根据权利要求4所述的基于Kubernetes的Pod调度方法，其特征在于，所述剩余可用带宽得分由工作节点在当前剩余可用带宽与期望剩余可用带宽值之间形成的正差值确定，其中，正差值越大，所述工作节点所对应的剩余可用带宽得分越高。

7.根据权利要求5或者6所述的基于Kubernetes的Pod调度方法，其特征在于，所述工作节点独立部署一连接守护进程组件的剩余可用带宽检查器，所述剩余可用带宽调度器连接调度器，所述调度器连接资源访问组件，以在所述资源访问组件中根据对工作节点所采集到的当前剩余可用带宽，以根据注入资源访问组件的对象资源配置文件所包含的基础剩余可用带宽值与期望剩余可用带宽值为条件，筛选出至少一个当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点；所述剩余可用带宽检查器监测工作节点的网卡，以确定工作节点的当前剩余可用带宽。

8.根据权利要求7所述的基于Kubernetes的Pod调度方法，其特征在于，所述Pod调度方法还包括：将筛选出的当前剩余可用带宽位于基础剩余可用带宽值与期望剩余可用带宽值之间的工作节点作为被过滤出的符合所述Pod请求的工作节点，并作为可调度工作节点池，并在接收到下一个Pod请求时，根据对象资源配置文件从可调度工作节点池中选取一个剩余可用带宽得分最高的工作节点作为响应下一个Pod请求的工作节点，其中，所述对象资源配置文件包括Yaml文件、JSON文件或者命令行。

9.基于Kubernetes的Pod调度系统，其特征在于，包括：

部署于主节点中的调度器、资源访问组件及剩余可用带宽调度器，部署于被主节点所纳管的若干工作节点中的守护进程组件及剩余可用带宽检查器；

在创建Pod请求时向所述资源访问组件添加剩余可用带宽配置值；

剩余可用带宽检查器确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

由所述调度器监测所述资源访问组件获取的Pod请求，并通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点，所述剩余可用带宽配置值以对象资源配置文件的形式注入资源访问组件；

由所述资源访问组件向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以通过所述资源访问组件将所述Pod请求在首调度阶段中绑定至所述工作节点。

10.一种云平台，其特征在于，包括：

主节点，以及若干被所述主节点所纳管的工作节点，

所述主节点部署资源访问组件及连接所述资源访问组件的运行管理控制器组件、调度器及ETCD组件，所述调度器连接剩余可用带宽调度器；所述工作节点部署守护进程组件、执行组件及剩余可用带宽检查器；

在创建Pod请求时向所述资源访问组件添加剩余可用带宽配置值；

剩余可用带宽检查器确定待被部署Pod的工作节点在当前状态中所形成的当前剩余可用带宽，并周期性地以心跳信息形式上报至资源访问组件；

由所述调度器监测所述资源访问组件获取的Pod请求，并通过部署于主节点中的剩余可用带宽调度器获取各个工作节点的当前剩余可用带宽，比较当前剩余可用带宽与所述剩余可用带宽配置值，以过滤出符合所述Pod请求的工作节点，所述剩余可用带宽配置值以对象资源配置文件的形式注入资源访问组件；

由所述资源访问组件向符合所述Pod请求的工作节点所属的守护进程组件予以响应，以通过所述资源访问组件将所述Pod请求在首调度阶段中绑定至所述工作节点。

Images