CN117729204A - 一种基于监控感知的k8s容器调度方法及系统 - Google Patents

Abstract

本发明属于服务调度及智能化运维领域，提供了一种基于监控感知的K8S容器调度方法及系统，其技术方案为：获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；基于时间序列数据，分别构建服务器节点画像和服务画像；基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案。本发明能够有效减少容器间跨节点通信以及容器间资源竞争，提升集群资源利用率和系统的响应性能。

Description

一种基于监控感知的K8S容器调度方法及系统

技术领域

本发明属于服务调度及智能化运维领域，尤其涉及一种基于监控感知的K8S（kubernetes，简称K8S）容器调度方法及系统。

背景技术

本部分的陈述仅仅是提供了与本发明相关的背景技术信息，不必然构成在先技术。

Kubernetes目前已经成为微服务容器化编排管理的事实标准。在Kubernetes中，可以投稿自定义配置创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

Kubernetes工具极大的简化了微服务编排管理工作的难度，提升了运维人员的工作效率，但是kubernetes在容器的调度上也存在着一些缺陷会对微服务系统运行产生一些不利的影响，如，容器间跨节点通信带来的网络延迟、容器间资源竞争导致的响应变慢、节点间负载不均衡以及资源利用率低等问题。虽然kubernetes允许通过一些亲和性/反亲和性配置来控制减少这些不利影响，但这无疑增加了运维人员的配置工作难度。此外默认调度器在调度时没有考虑全局性，只通过亲和/反亲和配置难以使系统的整体性能达到最优。

Kubernetes对于运营商来说似乎是一个完美的选择，但需要额外的调整。目前已经有许多基于Kubernetes的建议，以在各种用例中为容器提供最佳调度器，之前的部分关于调度器的优化工作考虑了容器的耦合情况，但是大都是从单一角度考虑，且没有考虑容器在不同时间段的实际资源需求情况。

发明内容

为了解决上述背景技术中存在的至少一项技术问题，本发明提供一种基于监控感知的K8S容器调度方法及系统，其通过对运行的Kubernetes容器进行监控来获取影响调度的一些关键指标，并提供动态规划算法来优化容器的调度，以期望达到全局最优。

为了实现上述目的，本发明采用如下技术方案：

本发明的第一方面提供一种基于监控感知的K8S容器调度方法，包括如下步骤：

获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；

基于时间序列数据，分别构建服务器节点画像和服务画像；

基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案；其中，所述基于动态规划算法对符合要求的节点进行评分包括：

若待调度容器为一个，对所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，若待调度容器有多个，计算当前容器的调度评分外，引入了调度到该节点对列表中其他容器调度影响评分，之后将容器调度到评分最高的节点。

进一步地，所述容器和节点运行时的多维监控指标数据包括容器间的网络通信情况，容器对cpu、内存的资源消耗情况及各节点的资源使用情况。

进一步地，所述服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况；所述服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量数据。

进一步地，对于初次部署的容器，服务画像数据来自于相应的部署文件。

进一步地，所述所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，包括：

通信评分的计算过程为：以服务画像中的通信耦合度为主，在部署服务的容器实例时，针对任意一个节点，该节点的通信评分值为该节点上已有容器与待调度容器之间的通信耦合度权重之和；

资源竞争评分的计算过程为：计算服务画像中实例对cpu和内存资源的实际需求数量，针对任意一个节点，该节点的资源竞争评分值为该节点上已有容器与待调度容器在各时间段的实际资源需求总数与实际资源的比值计算得到；

资源均衡评分的计算过程为：以服务画像中每个容器需要的最小cpu资源和内存资源数两个数据计算。

进一步地，针对任意一个节点，该节点的资源均衡评分为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度。

进一步地，在采用基于动态规划算法对符合要求的节点进行评分时，不进行完全递归，而是设置一个固定的递归层数。

本发明的第二方面提供一种基于监控感知的K8S容器调度方法，包括：

数据获取模块，被配置为获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；

画像构建模块，被配置为基于时间序列数据，分别构建服务器节点画像和服务画像；

调度模块，被配置为基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案；其中，所述基于动态规划算法对符合要求的节点进行评分包括：

若待调度容器为一个，对所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，若待调度容器有多个，计算当前容器的调度评分外，引入了调度到该节点对列表中其他容器调度影响评分，之后将容器调度到评分最高的节点。

进一步地，所述服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况；所述服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量数据。

进一步地，调度模块中，针对任意一个节点，该节点的资源均衡评分为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度。

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

针对利用单一的网络度量指标或者固定的资源需求指标进行调度只能在某些特定方面优化，无法做到全局最优的问题，本发明综合考虑容器间网络度量、集群资源使用情况等多种因素，基于监控数据构建容器和节点画像并在画像的基础上通过动态规划算法进行容器调度，能够有效减少容器间跨节点通信以及容器间资源竞争，提升集群资源利用率和系统的响应性能。

本发明附加方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

构成本发明的一部分的说明书附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。

图1是本发明实施例提供的一种基于监控感知的K8S容器调度方法整体流程图；

图2是本发明实施例提供的一种基于监控感知的K8S容器调度系统结构示意图。

具体实施方式

下面结合附图与实施例对本发明作进一步说明。

应该指出，以下详细说明都是例示性的，旨在对本发明提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本发明的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

针对利用单一的网络度量指标或者固定的资源需求指标进行调度只能在某些特定方面优化，无法做到全局最优的技术缺陷，本发明综合考虑容器间网络度量、集群资源使用情况等多种因素，基于监控数据构建容器和节点画像并在画像的基础上通过动态规划算法进行容器调度，能够有效减少容器间跨节点通信以及容器间资源竞争，提升集群资源利用率和系统的响应性能。

实施例一

如图1所示，本实施例提供一种基于监控感知的K8S容器调度方法，包括如下步骤：

S101：获取容器和节点运行时的多维监控指标数据；

本实施中，基于监控组件进行容器和节点监控数据的收集，包括容器间的网络通信情况，容器对cpu、内存等的资源消耗情况，各节点的资源使用情况等；

例如，可以通过借助Istio和Prometheus等监控工具收集容器和节点在运行时的监控指标数据。

例如，针对网络度量指标，主要采集istio_request_bytes_sum、istio_response_bytes_sum两个监控指标，它们分别包含请求和响应中传输的字节数。

针对资源使用情况，主要关注容器的cpu和内存使用数据，因此，可以采集container_cpu_usage_seconds_total和container_memory_usage_bytes两个指标数据。container_cpu_usage_seconds_total为容器的cpu累计占用时间，单位为秒，类型为Counter，可搭配rate()函数计算出给定容器在给定时间段内平均每秒使用的cpu时间。container_memory_usage_bytes表示容器当前使用的内存量，包括所有使用的内存，不管有没有被访问(包括cache,rss,swap等)。

获取多维监控指标数据后，对多维监控指标数据进行预处理，将各类指标数据进行结合并转换成统一的时间序列格式。

S102：基于得到的序列数据，进行统计分析，生成每个容器所属服务和服务器节点的画像信息；对于初次部署的容器，服务画像数据来自于相应的部署文件。

需要说明的是，因为在Kubernetes中容器是根据deployment文件生成，一个deployment文件的多个容器实例配置及资源需求大致相同，因此针对一个deployment文件的多个容器实例只需要创建一个统一的画像即可，为区别于容器实例画像，本发明统一用服务画像来表示对容器的画像。其中服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况等；服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量等数据。

针对任意一个容器，其所属服务的服务画像主要关注三个方面：容器与其他容器的通信耦合度、容器的最小部署需求情况及容器的实际资源需求变化情况。

因此针对任意一个容器服务，其画像可以表示为：

（1），

其中表示容器/>与其他服务的通信耦合情况，/>和/>表示容器需要的最小cpu资源和内存资源数，/>和/>表示在一个周期内不同时间段中容器对cpu和内存资源的实际需求数量。

下面将分别介绍每个指标的具体计算方式。

对于，其计算方法为：

（2），

其中为与服务/>有通信耦合的服务名称，/>值为两个服务的耦合权重值。

对于，该值通过来自Istio的网络度量指标计算得到，具体计算方式为：

（3），

其中表示服务/>和/>之间请求中传输的字节数，即来自istio_request_bytes_sum指标的值，/>表示服务/>和/>之间响应信息中传输的字节数，即来自istio_response_bytes_sum指标的值。

为便于计算，后续需要对值进行归一化处理。

针对尚未有监控数据的新部署服务，值可以根据部署文件中的亲和度配置进行设置，此时/>的值初始化设置为1。

和/>表示服务/>的每个容器实例需要的最小cpu资源和内存资源数，该指标值来自部署文件中的spec.containers[].resources.requests.cpu和spec.containers[].resources.requests.memory两个配置数据。

为了便于调度计算，在服务画像中需要对配置数据中的单位进行统一，其中的单位使用Mi,/>的单位为millicore (m)。Kubernetes中的一cpu相当于1个vCPU（1个超线程），将一个cpu划分为1000份，每一份就是一个millicore。

和/>的数据格式为长度m的数组，表示在过去的一个周期内不同时间段中服务a的每个实例对cpu和内存资源的实际需求数量，即：

，

，

一般情况下以一日为一个周期，将一个周期按小时分为24个时间段，即m=24，统计在不同时间段中容器的实际资源需求情况，数据取值来自container_cpu_usage_seconds_total和container_memory_usage_bytes两个指标数据，针对一个服务多个容器实例的情况，取多个实例的平均值。

针对尚未有监控数据的新部署服务和/>各时间段的值可以初始化设置为spec.containers[].resources.limits.cpu和spec.containers[].resources.limits.memory两个配置数据的值。

针对任意一个服务器节点，其画像主要关注两个方面：节点的cpu、内存等资源总量以及节点上当前运行的容器实例。即：

（4），

其中分别代表节点的cpu、内存资源总量，/>表示节点上目前在运行的容器实例集合。

节点实际的资源使用情况可以通过节点上目前在运行的容器实例所需的资源计算得到。

S103：基于得到的服务画像和节点画像，面向待调度容器，对每个节点进行评分，将容器调度到评分最高的节点；

S103中，对节点进行评分时主要考虑三个方面的因素，即通信评分、资源竞争评分、资源均衡评分。

首先计算节点的通信评分。

通信频繁、耦合度较高的容器若被调度在不同的节点上会带来网络延迟，在进行调度时应该考虑待调度容器与节点中现有容器间的通信耦合度，以节省容器间网络带宽，降低网络延迟。

因此，通信评分的计算主要以服务画像中的通信耦合度为主，在部署服务/>的容器实例时，针对任意一个节点/>，该节点的通信评分/>值为该节点上已有容器与待调度容器之间的通信耦合度权重之和，即：

（5），

其中表示服务/>与待调度服务/>之间有通信耦合，表示该节点上有服务/>的容器实例在运行。

其次计算节点的资源竞争评分。

节点中资源不足会产生容器间资源竞争，资源竞争对服务性能有很大的影响，在调度时应该尽量避免服务容器间有过多的资源竞争，以免对服务性能产生不利影响。

因此，资源竞争评分计算主要服务画像中实例对cpu和内存资源的实际需求数量和/>为主，针对任意一个节点/>，该节点的资源竞争评分/>值为该节点上已有容器与待调度容器在各时间段的实际资源需求总数与实际资源的比值计算得到，即：

（6），

（7），

（8），

其中，表示节点的cpu资源竞争评分，/>表示节点的内存资源竞争评分，/>表示服务/>的容器实例在第/>个时间周期内对cpu资源的需求量，/>表示服务/>的容器实例在第/>个时间周期内对cpu资源的需求量，/>表示节点/>上的cpu资源总量，同理，/>表示服务/>的容器实例在第/>个时间周期内对内存资源的需求量，/>表示服务/>的容器实例在第/>个时间周期内对内存资源的需求量，/>表示节点上的内存资源总量。

最后计算节点的资源均衡评分。

资源均衡评分主要用来减少资源碎片，提高容器的部署成功率，计算时以服务画像中每个容器需要的最小cpu资源和内存资源数和/>两个数据为主。

为减少资源碎片，提高负载均衡度，在调度过程中需要使每个节点的资源使用率均衡化。先分析整体的资源使用情况，根据所有的pod调度需求和节点资源情况计算整体的cpu使用率cpuRate、内存使用率menRate、资源需求倾斜率rdi，计算方式如下：

（9），

（10），

（11），

其中表示集群中的所有工作节点的集合，/>表示服务/>要部署的容器实例个数。

根据整体的资源使用情况，为减少资源碎片、提高负载均衡度，调度过程中使每个节点的资源使用率趋向整体资源利用率。

因此，针对任意一个节点，该节点的资源均衡评分/>值为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度，即：

(12)，

其中、/>、/>分别代表容器调度到该节点后该节点的cpu使用率、内存使用率以及资源需求倾斜率。

当待调度容器有多个时，针对待调度容器列表中的每一个容器，在对节点进行最终评分时除了对当前容器的调度评分外还引入了调度到该节点对列表中其他容器调度影响评分，即：

(13)，

其中表示容器调度到节点/>上的调度评分，/>表示若容器调度到该节点上后剩余容器的最大调度评分，/>为衰减系数。

为提高调度效率，本发明在通过动态规划算法计算评分时不进行完全递归，而是设置一个固定的递归层数，这样虽然在一定概率上不能得到全局最优结果，但是能大幅度提高调度效率。

基于最终的评分结果，将容器调度到评分最高的节点。

表1描述了分别使用Kubernetes默认调度器和本发明提出的调度器进行调度后测试系统的性能比对。

表1本发明和默认调度器的性能对比

可以看到，相对于默认调度器的调度结果，本发明所使用调度器在相同时间内能够处理更多的请求，请求的平均响应时间提升28.57%，均好于对比方法。

实施例二

如图2所示，本实施例提供一种基于监控感知的K8S容器调度系统，包括：

数据获取模块，被配置为获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；

画像构建模块，被配置为基于时间序列数据，分别构建服务器节点画像和服务画像；

调度模块，被配置为基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案；其中，所述基于动态规划算法对符合要求的节点进行评分包括：

若待调度容器为一个，对所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，若待调度容器有多个，计算当前容器的调度评分外，引入了调度到该节点对列表中其他容器调度影响评分，之后将容器调度到评分最高的节点。

其中，画像构建模块中，所述服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况；所述服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量数据。

其中，调度模块中，针对任意一个节点，该节点的资源均衡评分为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度。

实施例三

本实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如实施例一所述的一种基于监控感知的K8S容器调度方法中的步骤。

实施例四

本实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如实施例一所述的一种基于监控感知的K8S容器调度方法中的步骤。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于监控感知的K8S容器调度方法，其特征在于，包括如下步骤：

获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；

基于时间序列数据，分别构建服务器节点画像和服务画像；

基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案；其中，所述基于动态规划算法对符合要求的节点进行评分包括：

若待调度容器为一个，对所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，若待调度容器有多个，计算当前容器的调度评分外，引入了调度到该节点对列表中其他容器调度影响评分，之后将容器调度到评分最高的节点。

2.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，所述容器和节点运行时的多维监控指标数据包括容器间的网络通信情况，容器对cpu、内存的资源消耗情况及各节点的资源使用情况。

3.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，所述服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况；所述服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量数据。

4.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，对于初次部署的容器，服务画像数据来自于相应的部署文件。

5.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，所述所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，包括：

通信评分的计算过程为：以服务画像中的通信耦合度为主，在部署服务的容器实例时，针对任意一个节点，该节点的通信评分值为该节点上已有容器与待调度容器之间的通信耦合度权重之和；

资源竞争评分的计算过程为：计算服务画像中实例对cpu和内存资源的实际需求数量，针对任意一个节点，该节点的资源竞争评分值为该节点上已有容器与待调度容器在各时间段的实际资源需求总数与实际资源的比值计算得到；

资源均衡评分的计算过程为：以服务画像中每个容器需要的最小cpu资源和内存资源数两个数据计算。

6.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，针对任意一个节点，该节点的资源均衡评分为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度。

7.如权利要求1所述的一种基于监控感知的K8S容器调度方法，其特征在于，在采用基于动态规划算法对符合要求的节点进行评分时，不进行完全递归，而是设置一个固定的递归层数。

8.一种基于监控感知的K8S容器调度系统，其特征在于，包括：

数据获取模块，被配置为获取容器和节点运行时的多维监控指标数据，并预处理得到时间序列数据；

画像构建模块，被配置为基于时间序列数据，分别构建服务器节点画像和服务画像；

调度模块，被配置为基于服务器节点画像和服务画像，面向待调度容器，基于动态规划算法对符合要求的节点进行评分，将容器调度到评分最高的节点，得到最优调度方案；其中，所述基于动态规划算法对符合要求的节点进行评分包括：

若待调度容器为一个，对所有节点分别从通信评分、资源竞争评分、资源均衡评分角度分别进行综合评分，若待调度容器有多个，计算当前容器的调度评分外，引入了调度到该节点对列表中其他容器调度影响评分，之后将容器调度到评分最高的节点。

9.如权利要求8所述的一种基于监控感知的K8S容器调度系统，其特征在于，画像构建模块中，所述服务器节点画像包含服务器节点的资源总量、在不同时间段的资源使用情况以及当前运行在节点上的容器情况；所述服务画像包含容器在不同时间段的资源需求情况、容器与其他容器的网络通信度量数据。

10.如权利要求8所述的一种基于监控感知的K8S容器调度系统，其特征在于，调度模块中，针对任意一个节点，该节点的资源均衡评分为容器调度到该节点后该节点的资源利用率与整体资源利用率的相似度，将节点资源利用率与整体资源利用率分别看作两个向量，通过两个向量间欧式距离的反比来评估节点的资源利用率与整体资源利用率的相似度。