CN114327023A - 一种Kubernetes集群的节能方法、系统、计算机介质和电子设备 - Google Patents

Abstract

本申请提供了一种Kubernetes集群的节能方法、系统、计算机可读存储介质和电子设备。该方法包括：确定所述Kubernetes集群的访问流量的变化趋势；响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述第一节点小组中的全部节点进入休眠状态；所述第一节点小组和所述第二节点小组分别包括至少一个节点；或者响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群上的部分应用调度至唤醒后的节点上。籍此，使得Kubernetes系统能够根据访问流量的变化趋势，对Kubernetes集群的整体工作性能进行自动扩缩容，降低了电力消耗。

Description

一种Kubernetes集群的节能方法、系统、计算机介质和电子 设备

技术领域

本申请涉及云原生技术领域，特别涉及一种Kubernetes集群的节能方法、系统、计算机可读存储介质和电子设备。

背景技术

在云原生场景下，集群管理员通常将同一个数据中心的多个节点(即服务器)纳入一个Kubernetes集群进行管理，借助Kubernetes系统所具有的自动化部署、大规模可伸缩、应用容器化管理等特点，实现对数据中心的自动化运行维护。

在将应用部署在Kubernetes集群中的一个节点上之后，Kubernetes系统会根据应用的硬件资源使用情况，对应用进行自动化扩缩容。比如在访问高峰期，根据使用情况对应用进行扩容，即逐步增加部署应用的容器组数据，在访问低谷期，根据使用情况对应用进行缩容，即逐步减少部署应用的容器组数量，直至只保留一个容器组，甚至不保留任何容器组。

也就是说，为了让应用在访问高峰期来临时，能够自动对应用进行扩容，支撑访问高峰期的需求，在访问低谷期，Kubernetes集群中的每个节点依然需要开机运行，哪怕每个节点上只剩一个容器组还在运行，节点上的CPU、内存、硬盘等基础硬件仍需要处于运行状态，浪费了大量电力。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种Kubernetes集群的节能方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种Kubernetes集群的节能方法，包括：确定所述Kubernetes集群的访问流量的变化趋势；响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述第一节点小组中的全部节点进入休眠状态；所述第一节点小组和所述第二节点小组分别包括至少一个节点；或者，响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群上的部分应用调度至唤醒后的节点上。

优选的，所述确定Kubernetes集群的访问流量的变化趋势，包括：采集部署在所述Kubernetes集群上的每个应用的历史访问数据；根据所述每个应用的历史访问数据，确定所述Kubernetes集群的访问高峰期和访问低谷期的时间段。

优选的，所述确定Kubernetes集群的访问流量的变化趋势，包括：采集所述Kubernetes集群中的每个节点的资源使用情况；当所述Kubernetes集群中资源使用量超过预设第一阈值的节点数量超过预设第二阈值时，确定所述Kubernetes集群进入访问高峰期；当所述Kubernetes集群中资源使用量低于预设第三阈值的节点数量超过第四阈值时，确定所述Kubernetes集群进入访问低谷期。

优选的，所述响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，包括：根据所述Kubernetes集群的历史访问数据，确定所述Kubernetes集群的访问低谷期的访问量；响应于所述Kubernetes集群进入访问低谷期，根据确定的所述访问低谷期的访问量，确定所述第一节点小组和所述第二节点小组对应的节点；根据所述第二节点小组中的每个节点的资源使用情况，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上。

优选的，所述根据确定的所述访问低谷期的访问量，确定所述第一节点小组和所述第二节点小组对应的节点，包括：根据所述访问低谷期的访问量和预设工作模式，确定在所述预设工作模式下，所述Kubernetes集群在所述访问低谷期对应的资源使用类型和资源使用量；根据所述资源使用类型和资源使用量，确定所述Kubernetes集群上的全部应用在所述访问低谷期的部署方式，并将所述部署方式对应的全部节点作为所述第二节点小组。

优选的，在所述Kubernetes集群中的每个节点上设置有BMC硬件模块，对应的，所述响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，包括：根据所述Kubernetes集群的历史访问数据，确定所述Kubernetes集群的访问高峰期的访问量；在所述Kubernetes集群进入访问高峰期之前，根据确定的所述访问期的访问量，确定需要进行唤醒的节点，并通过所述BMC硬件模块提供的API接口对所述Kubernetes集群中的处于休眠状态的节点进行唤醒。

优选的，所述的Kubernetes集群的节能方法还包括：采集所述Kubernetes集群中的每个节点的资源使用情况；根据所述节点的资源使用情况，确定所述Kubernetes集群的资源使用情况；当所述Kubernetes集群的空闲资源量超过预设第五阈值，或者所述Kubernetes集群的空闲资源比例超过预设第六阈值时，将部署在所述Kubernetes集群中资源使用量最小的节点上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述资源使用量最小的节点进入休眠状态；当所述Kubernetes集群的空闲资源量低于预设第七阈值，或者所述Kubernetes集群的空闲资源比例低于预设第八阈值时，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群中资源使用量最大的应用调度至唤醒后的节点上。

本申请实施例还提供一种Kubernetes集群的节能系统，包括：趋势单元，配置为确定所述Kubernetes集群的访问流量的变化趋势；节点调度单元，配置为响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述第一节点小组的全部节点进入休眠状态；所述第一节点小组和所述第二节点小组分别包括至少一个节点；或者，响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群上的部分应用调度至唤醒后的节点上。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的Kubernetes集群的节能方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的Kubernetes集群的节能方法。

有益效果：

本申请中通过确定Kubernetes集群的访问流量的变化趋势，来调整Kubernetes集群中分别处于运行状态和休眠状态的节点。当访问流量处于下降趋势时，响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群中的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制第一节点小组中的全部节点进入休眠状态。当访问流量处于上升趋势时，响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群上的部分应用调度至唤醒后的节点上。通过Kubernetes集群的访问流量的变化趋势，实现对Kubernetes集群中需要正常运行节点进行确定。在访问流量下降时，将Kubernetes集群中一部分处于运行状态的节点转入休眠状态，减少节点发热量，降低能耗。在访问流量上升时，将Kubernetes集群中一部分处于休眠状态的节点进行唤醒，并将部分应用调度至唤醒后的节点上，使得Kubernetes集群的整体性能能够对访问流量正常响应。籍此，使得Kubernetes系统能够根据容器化部署的应用的使用情况，实现对Kubernetes集群的整体资源进行自动扩缩容，在Kubernetes集群处于访问低谷期时，将集群中的部分节点休眠，并在访问高峰期来临之前，唤醒部分或全部休眠的节点，既降低了电力消耗，又保证了集群的工作性能。

附图说明

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

图1为根据本申请的一些实施例提供的一种Kubernetes集群的节能方法的流程示意图；

图2为根据本申请的一些实施例提供的一种Kubernetes集群的节能方法原理示意图；

图3为根据本申请的一些实施例提供的一种Kubernetes集群的节能系统的结构示意图；

图4为根据本申请的一些实施例提供的电子设备的结构示意图；

图5为根据本申请的一些实施例提供的电子设备的硬件结构。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在云原生场景下，集群管理员通常将同一个数据中心中的多个节点(即服务器)纳入一个Kubernetes集群进行管理。借助Kubernetes系统所具有的自动化部署、大规模可伸缩、应用容器化管理等特点，实现对数据中心的自动化运行维护。

在将应用部署在Kubernetes集群中的一个节点上之后，Kubernetes系统会根据应用的资源使用情况，对应用进行自动化扩缩容。比如在应用的访问流量增大时，根据使用情况对应用进行扩容，即逐步增加部署应用的容器组数量，在应用的访问流量减小时，根据使用情况对应用进行缩容，即逐步减少部署应用的容器组数量，直至只保留一个容器组，甚至不保留任何容器组。

也就是说，为了让应用在访问流量增大时，能够自动对应用进行扩容，支撑访问高峰期的需求，在访问低谷期，Kubernetes集群中的每个节点依然需要开机运行，哪怕每个节点上只剩一个容器组还在运行，节点上的CPU、内存、硬盘等基础硬件仍需处于运行状态，浪费了大量电力。

申请人为了解决上述问题，对Kubernetes集群所在机房的耗电情况进行深入分析后发现，Kubernetes集群所在机房的耗电量主要是节点和空调产生的，而空调的耗电量增加主要是由于节点发热量过大，间接造成空调耗电增加，因此，降低节点本身的消耗量和减少机电的发热量是减少整个机房耗电量的关键。

经过对节点的访问量和耗电量进行长期监测和分析后，发现节点的CPU是节点最大的耗电源和发热源。对于Kubernetes集群中的每个节点，CPU是必不可少的硬件，而只要节点处在开机运行状态，CPU就处于运行中，自身大量耗电并发出热量，进而又导致空调的耗电量随之增加。

在工程实践中，Kubernetes集群中节点数量是根据数据中心需要同时响应的最大访问量来确定的，也就是根据访问高峰期的最大峰值来设置节点数量，而在访问低谷期，Kubernetes集群中的大部分资源处于闲置状态，而数据中心的访问低谷期的时长是一般远远高于访问高峰期的。经过长期监测、分析和估算，CPU的使用率大约只有20％，也就是说，在大量的时间段内，Kubernetes集群中节点的CPU处于高耗电、高发热、低使用状态，浪费了大量电力。

基于此，本申请提出了一种Kubernetes集群的节能方法，在集群的访问流量较小，即对访问流量进行响应所需的资源使用量较小时，让集群中的部分节点进入休眠状态，以减少CPU的耗电量和发热量，进而减少机房耗电量。具体来说，就是在访问流量较小时，将集群内全部节点上部署的应用通过重调度机制集中至一部分节点上运行，以较少的资源维持应用的正常运行，使集群中没有应用部署的空闲节点进入休眠状态，让CPU暂时停止运行，以节省电力消耗。同时，为保证在访问流量较大时能够对访问请求进行响应，在访问流量高峰到来之前，将处于休眠状态的部分或者全部节点唤醒，并恢复至正常运行状态，让Kubernetes系统能够使用唤醒节点上的资源，使用重调度机制将应用重新部署在唤醒后的节点上。

图1为根据本申请的一些实施例提供的一种Kubernetes集群的节能方法的流程示意图；如图1所示，该Kubernetes集群的节能方法包括：

步骤S101、确定Kubernetes集群的访问流量的变化趋势。

基于前述说明，可以知道，本申请实施例所提出的一种Kubernetes集群的节能方法能够既满足节能的需求又满足对访问流量进行正常响应的需求，关键在于在某一合适的时间点将部分处于正常运行状态的节点转入休眠状态，再在另一合适的时间点将部分或全部处于休眠状态的节点进行唤醒，以及在访问流量较为平稳时，让Kubernetes集群中处于正常运行状态的节点保持不变。

本申请实施例通过确定集群的访问流量的变化趋势，以在合适的时间点对Kubernetes集群中处于正常运行状态的节点进行调整。

具体地，可以将Kubernetes集群的运行状态划分为访问高峰期和访问低谷期，当Kubernetes集群由访问高峰期进入访问低谷期后，将部分处于正常运行状态的转入休眠状态，在Kubernetes集群由访问低谷期进入访问高峰期之前，将部分或全部处于休眠状态的节点进行唤醒，当Kubernetes集群没有在访问高峰期和访问低谷期之间进行切换时，让Kubernetes集群中处于正常运行状态的节点保持不变。

需要说明的是，采用划分访问高峰期和访问低谷期的方式来调整Kubernetes集群中处于正常运行状态的节点，当Kubernetes集群由访问高峰期进入访问低谷期后，即便没有及时将部分处于正常运行状态的转入休眠状态，造成的后果只是额外消耗一些电力，并不会对Kubernetes集群对外部访问流量进行响应造成影响。而在Kubernetes集群由访问低谷期进入访问高峰期之前，如果没有预先将部分或全部处于休眠状态的节点进行唤醒，那么当访问高峰期到来时，可能会因为Kubernetes集群的整体资源无法满足对访问流量进行响应的需求，而导致部署在Kubernetes集群上的应用无法及时响应，甚至导致整个Kubernetes集群出现崩溃，因此需要在访问高峰期到来之前就对节点进行唤醒。

进一步地，在将Kubernetes集群的运行状态划分为访问高峰期和访问低谷期时，本申请实施例提出了不同的划分依据，既可以通过Kubernetes集群中应用的访问历史数据确定，也可以根据Kubernetes集群中的资源使用情况来确定。

在一具体的例子中，步骤S101中的确定Kubernetes集群的访问流量的变化趋势，包括：采集部署在Kubernetes集群上的每个应用的历史访问数据，并根据每个应用的历史访问数据，确定Kubernetes集群的访问高峰期和访问低谷期的时间段。

通常情况下，对Kubernetes集群来说，访问高峰期和访问低谷期、以及每个期间访问流量的峰值大小呈现出周期性的变化趋势，比如每天的18～20点为访问高峰期，而每天的凌晨2～6点为访问低谷期；逢年过节时电商、电子支付数据中心的访问量远远大于平时等等。因此，可以根据部署在Kubernetes集群上的每个应用的历史访问数据对Kubernetes集群的访问高峰期和访问低谷期的时间段进行确定。

具体来说，将部署在Kubernetes集群上的每个应用的历史访问量在时间上进行叠加，即可得到整个Kubernetes集群的历史访问量，进而对Kubernetes集群的历史访问量进行分析、确定，得到Kubernetes集群的访问高峰期和访问低谷期的时间段。

在另一具体的例子中，步骤S101中的确定Kubernetes的访问流量的变化趋势包括：采集Kubernetes集群中的每个节点的资源使用情况。当Kubernetes集群中资源使用量超过预设第一阈值的节点数量超过预设第二阈值时，确定Kubernetes集群进入访问高峰期。当Kubernetes集群中资源使用量低于预设第三阈值的节点数量超过预设第四阈值时，确定Kubernetes集群进入访问低谷期。

需要说明的是，申请人经过对Kubernetes集群的运行日志数据进行分析后发现，当Kubernetes集群即将从访问高峰期进入访问低谷期，Kubernetes集群上大部分节点的资源使用量开始出现显著减少，当Kubernetes集群即将从访问低谷期进入访问高峰期，Kubernetes集群上大部分节点的资源使用量开始出现显著增长。基于此，本申请实施例通过Kubernetes集群中资源使用量高于高峰阈值的节点数量超过数量上限，以及资源使用量低于低谷阈值的节点数量超过数量上限，来分别确定Kubernetes集群的整体资源使用量开始出现显著增长和显著减少，进而分别判定Kubernetes集群即将进入访问高峰期和访问低谷期。

在本申请实施例中，当检测到Kubernetes集群中第一预设数量(即预设第一阈值)的节点的资源使用量超过预设高峰阈值(即预设第二阈值)时，判定Kubernetes集群进入访问高峰期。当检测到Kubernetes集群中第二预设数量(即预设第三阈值)的节点的资源使用量低于预设低谷阈值(即预设第四阈值)时，判定Kubernetes集群进入访问低谷期。

为了采集Kubernetes集群中的每个节点的资源使用情况，本申请实施例可以在每个节点上部署BMC(Baseboard Management Controller，基板管理控制器)硬件模块或者Prometheus软件系统，通过访问BMC硬件模块提供的API接口或者Prometheus软件系统的访问接口获取Kubernetes集群中每个节点的实时资源使用情况。

采用部署BMC硬件模块的方式时，在Kubernetes集群的每个工作节点上设置BMC硬件模块和用于外部访问的BMCAPI接口，并在Kubernetes集群中容器化部署的节能控制器。设置在每个节点上的BMC硬件模块通过多个传感器收集所在节点的资源使用情况，包括但不限于CPU、内存、硬盘使用情况等，节能控制器中的资源使用情况收集模块通过访问BMC硬件模块提供的API接口获取Kubernetes集群中每个节点的资源使用情况。

步骤S102a、响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群中的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制第一节点小组中的全部节点进入休眠状态。

其中，第一节点小组和第二节点小组中分别包括至少一个节点。

基于前述说明，可以知道，本申请实施例在访问低谷期，将集群内全部节点上部署的应用通过重调度机制集中至一部分节点上运行，以较少的硬件资源维持应用的正常运行，使集群中没有应用部署的空闲节点进入休眠状态，使CPU暂时停止运行，以节省电力消耗。

但在将集群内全部节点上部署的应用通过重调度机制集中至一部分节点上运行之前，需要先确定将哪些节点转入休眠状态，即确定前述第一节点小组和第二节点小组分别对应的哪些节点。

在一具体的例子中，响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群中的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，包括：根据Kubernetes集群的历史访问数据，确定Kubernetes集群的访问低谷期的访问量。响应于Kubernetes集群进入访问低谷期，根据确定的访问低谷期的访问量，确定第一节点小组和第二节点小组对应的节点。根据第二节点小组中的每个节点的资源使用情况，将部署在Kubernetes集群中的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上。

需要说明的是，本申请实施例在采集了部署在Kubernetes集群上的每个应用的历史访问数据后，不仅可以据此确定访问低谷期的时间段，还可以确定应对本次访问低谷期的访问流量所需的节点。具体来说，根据每个应用的历史访问数据，可以预测出在本次访问低谷期中每个应用对应的访问流量，进而确定每个应用需要使用的资源类型和资源数量，通过算法与Kubernetes集群中每个节点能够提供的资源类型和资源数量进行匹配，再考虑Kubernetes集群中每个节点的耗电情况，最终确定在本次访问低谷期保持正常运行状态的节点(即第二节点小组中的节点)和转入休眠状态的节点(即第一节点小组中的节点)。

由于第二节点小组中的节点上原本部署有应用，在将第一节点小组中的节点上的全部应用调度至第二节点小组中的节点上时，可以在第二节点小组中资源类型相同的若干节点中，根据每个节点的资源使用情况，最终确定调度的节点，完成应用的调度。

需要说明的是，由于在生产实践中，不同用户对Kubernetes集群的节能要求可能存在区别。比如有些Kubernetes集群的访问流量仅在每年的特定几小时内出现高峰，其他时间几乎处于零访问状态，该类Kubernetes集群的运维管理人员希望在平常时间将Kubernetes集群的电力消耗压至越低越好。比如有些Kubernetes集群的访问流量会在部分时间段出现明显高峰，而在其他大部分时间访问流量处于低访问状态，但是偶尔也会出现一些小的访问流量高峰，该类Kubernetes集群的运维管理人员一方面希望在平常时间将Kubernetes集群的电力消耗压低，另一方面又担心万一出现偶发的流量高峰，会导致部署在集群上的应用不可用，甚至Kubernetes集群出现崩溃。

基于此，本申请实施例允许集群运维管理人员对Kubernetes集群预先设置工作模式，在不同工作模式下，Kubernetes集群在进入访问低谷期后，全部应用的部署方式会存在区别。

具体来说，前述根据确定的访问低谷期的访问量，确定第一节点小组和第二节点小组对应的节点，包括：根据访问低谷期的访问量和预设工作模式，确定在预设工作模式下，Kubernetes集群在访问低谷期对应的资源使用类型和资源使用量。根据资源使用类型和资源使用量，确定Kubernetes集群上的全部应用在访问低谷期的部署方式，并将部署方式对应的全部节点作为第二节点小组。

基于前述说明，可以知道，本申请实施例先预测出在本次访问低谷期中每个应用对应的访问流量，进而确定每个应用需要使用的资源类型和资源数量，再确定在本次访问低谷期需要保持正常运行状态的节点(即第二节点小组中的节点)。

而在不同预设工作模式下，虽然每个应用需要使用的资源类型和资源数量保持不变，但需要为每个保持正常运行状态的节点保留不同的资源使用冗余。

具体地，节能控制器可以通过各个节点上部署BMC硬件模块提供的API接口获取所在节点的资源使用情况，并对Kubernetes集群中每个节点的资源使用情况进行统计和分析，根据预设工作模式(比如，节能优先模式、性能优先模式、性能全开模式)，计算和生成该预设工作模式下最佳调度策略，并由节能控制器的节点休眠唤醒模块指示控制节点上的Scheduler组件基于最佳调度策略，通过API-Server组件对集群中的应用进行重调度。

需要说明的是，节能控制器可以部署在Kubernetes集群中的任一节点上，节能控制器根据预设工作模式生成对应的最佳调度策略时，需要对集群中每个节点的资源使用情况进行充分收集和计算，并利用组合优化算法，从集群层面确定最佳调度策略。

具体来说，当预设工作模式为节能优先模式时，只保留尽量少的节点(作为第二节点小组)正常运行，让集群中的大多数节点(作为第一节点小组)进入休眠状态，正常运行的节点上的资源被应用充分使用。比如说，在将集群中的应用全部集中调度至保持正常运行状态的节点(即第二节点小组中的节点)后，每个处于正常运行状态的节点上的资源使用率达到80％～90％，仅保留10％～20％的资源使用冗余以应对偶发访问高峰。在节能优先模式下，运行节点(即第二节点小组中的节点)的数量极少，能够极大地降低电力消耗。

当预设工作模式为性能优先模式时，则会保留足够多的节点正常运行，让集群中的少部分节点(作为第一节点小组)进入休眠状态，大部分节点(即第二节点小组中的节点)仍处于正常运行状态。比如说，在将集群中的应用调度至保持正常运行状态的节点(即第二节点小组中的节点)后，每个处于正常运行状态的节点上的资源使用率达到60％～70％，保留30％～40％的资源使用冗余，相应地，让集群中40％～50％的节点(即第一节点小组中的节点)进入休眠状态，剩余50％～60％的节点(即第二节点小组中的节点)保持正常运行状态。在性能优先模式下，只有少部分节点需要唤醒，在访问高峰期到来前，能够在短时间内让集群性能恢复正常，既降低了电力消耗，又能够实现集群性能的快速恢复。

在性能全开模式下，则会让集群中的全部节点保持正常运行，没有节点进入休眠状态，因此，也无需进行应用的调度，在此不再赘述。

籍此，本申请实施例可以根据实际需求设置不同的工作模式，以适应不同业务类型的Kubernetes集群。

步骤S102b、响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群上的部分应用调度至唤醒后的节点上。

基于前述说明，可以知道，本申请实施例在访问高峰期到来之前，将集群中处于休眠状态的至少一个节点进行唤醒，以增加整个集群的可用资源量，并将部分应用调度至唤醒后的节点上，以分担整个集群的资源使用压力。

需要说明的是，可以使用Kubernetes系统自带的优雅关机功能将Kubernetes集群中的部分节点转入休眠状态，但是当节点处于休眠状态时，部署在该节点上的Kubernetes系统的组件没有启动，Kubernetes集群无法直接对该节点进行唤醒，因此需要通过BMC硬件模块对节点进行唤醒。

在一些可选实施例中，Kubernetes集群中的每个节点上设置有BMC硬件模块，对应的，响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，包括：根据Kubernetes集群的历史访问数据，确定Kubernetes集群的访问高峰期的访问量。在Kubernetes集群进入访问高峰期之前，根据确定的访问高峰期的访问量，确定需要进行唤醒的节点，并通过BMC硬件模块提供的API接口对Kubernetes集群中的处于休眠状态的节点进行唤醒。

可以理解，在本申请实施例中，可以根据每个应用的历史访问数据对本次访问高峰期中最大峰值访问量、以及应对最大峰值访问量所需的资源类型和资源使用量进行估算，进而确定集群中全部应用响应本次访问高峰期的访问流量所需唤醒的节点。在访问高峰期到来之前，节能控制器的节点休眠控制模块按照估算结果，通过远程访问休眠节点的BMC硬件模块提供的API接口，唤醒处于休眠状态的节点，并指示控制节点上的Scheduler组件根据估算结果，通过API-Server组件将应用调度至唤醒后的节点。

前述实施例将Kubernetes集群的运行状态划分为访问高峰期和访问低谷期，但本申请实施例还可以不对Kubernetes集群的运行状态进行不同时期的划分，而是通过集群中资源的使用情况来实时监测访问流量的变化趋势，实时动态调整Kubernetes集群中处于正常运行状态的节点。

在一些可选实施例中，Kubernetes集群的节能方法还包括：采集Kubernetes集群中每个节点的资源使用情况。根据节点的资源使用情况，确定Kubernetes集群的资源使用情况，当Kubernetes集群的空闲资源量超过预设第五阈值，或者Kubernetes集群的空闲资源比例超过预设第六阈值时，将部署在Kubernetes集群中资源使用量最小的节点上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制资源使用量最小的节点进入休眠状态。当Kubernetes集群的空闲资源量低于预设第七阈值，或者Kubernetes集群的空闲资源比例低于预设第八阈值时，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群中资源使用量最大的应用调度至唤醒后的节点上。

具体来说，当节能控制器中的资源使用情况收集模块检测到Kubernetes集群中的空闲资源超过预设休眠阈值(即预设第五阈值)或者空闲资源比例超过预设休眠比例(即预设第六阈值)时，说明当前Kubernetes集群的资源使用存在一定的冗余，可以将Kubernetes集群中资源使用量最小的节点上的应用全部调度至其它节点，并指示该节点进入休眠状态。当节能控制器中的资源使用情况收集模块检测到Kubernetes集群中的空闲资源低于预设过载阈值(即预设第七阈值)或者空闲资源比例低于预设过载比例(即预设第八阈值)时，说明当前Kubernetes集群的资源使用存在一定的紧缺，可以唤醒至少一台休眠节点，并将资源使用量最高的应用调度至唤醒后的节点上。

可以理解，采用实时动态调整Kubernetes集群中处于正常运行状态的节点的方案，可以更加精细化地调整Kubernetes集群的电力消耗和整体可用资源量。

此外，本申请实施例还可以将前述的调整Kubernetes集群中处于正常运行状态的节点的实现方式相结合，即将历史访问数据和每个节点的资源使用量相结合，来划分访问高峰期和访问低谷期，在访问高峰期和访问低谷期切换时，粗犷地调整Kubernetes集群中处于正常运行状态的节点，根据节点的资源使用情况，实时动态精细地调整Kubernetes集群中处于正常运行状态的节点，本申请实施例对此不做限定。

在本申请实施例中，得益于Kubernetes系统的自动化部署、大规模可伸缩、应用容器化管理等功能，使得Kubernetes集群内的应用部署和调度能够在几分钟内完成，因此可以实现在每天的大部分时间段内让集群的部分或者大部分节点处于休眠状态，在访问高峰期到来之前，在几分钟内将休眠节点唤醒，既降低了电力消耗，又不影响数据中心性能。

在本申请实施例中，通过在节点上设置BMC硬件模块采集所在节点的资源使用情况，在Kubernetes集群处于访问低谷期时，使用节能控制器将集群中的部分节点休眠，并在访问高峰期来临之前，唤醒休眠的节点，既降低了电力消耗，又保证了集群的工作性能。利用Kubernetes系统所具有的调度性能，实现应用在Kubernetes集群内的快速调度。

在此，需要说明的是，通过BMC硬件模块还可以收集所在节点的耗电情况(能耗信息)，对机房的耗电情况进行统计分析，不断优化最佳调度策略的生成方法和访问高峰期的最大峰值访问量估算方法，不断优化Kubernetes集群的节能方法。随着Kubernetes集群运行时间的增加，所得到的峰值访问量/低谷访问量所需使用资源量的估算结果将越来越准确，根据估算结果所确定的节点唤醒/休眠的数量和时间点将越加准确，制定出的最佳调度策略也将与实际情况愈发吻合，节能效果将越来越好。

示例性系统

图3为根据本申请的一些实施例提供的一种Kubernetes集群的节能系统的结构示意图；如图3所示，该Kubernetes集群的节能系统包括：趋势单元，配置为确定Kubernetes集群的访问流量的变化趋势。节点调度单元，配置为响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制第一节点小组的全部节点进入休眠状态；第一节点小组和第二节点小组分别包括至少一个节点；或者，响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群上的部分应用调度至唤醒后的节点上。

本申请实施例提供的Kubernetes集群的节能系统能够实现上述任一Kubernetes集群的节能方法实施例的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图4为根据本申请的一些实施例提供的电子设备的结构示意图；如图4所示，该电子设备包括：

一个或多个处理器401；

计算机可读介质，可以配置为存储一个或多个程序402，一个或多个处理器401执行一个或多个程序402时，实现如下步骤：

确定Kubernetes集群的访问流量的变化趋势；响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制第一节点小组的全部节点进入休眠状态；第一节点小组和第二节点小组分别包括至少一个节点；或者，响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群上的部分应用调度至唤醒后的节点上。

图5为根据本申请的一些实施例提供的电子设备的硬件结构，如图5所示，该电子设备的硬件结构可以包括：处理器501、通信接口502、计算机可读介质503和通信总线504。

其中，处理器501、通信接口502、计算机可读介质503通过通信总线504完成相互间的通信。

可选地，通信接口502可以为通信模块的接口，如GSM模块的接口。

其中，处理器501具体可以配置为：确定Kubernetes集群的访问流量的变化趋势；响应于Kubernetes集群的访问流量处于下降趋势，将部署在Kubernetes集群的第一节点小组上的全部应用调度至Kubernetes集群中的第二节点小组上，并控制第一节点小组的全部节点进入休眠状态；第一节点小组和第二节点小组分别包括至少一个节点；或者，响应于Kubernetes集群的访问流量处于上升趋势，对Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将Kubernetes集群上的部分应用调度至唤醒后的节点上

处理器可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的Kubernetes集群的节能方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

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

Claims (10)

1.一种Kubernetes集群的节能方法，其特征在于，包括：

确定所述Kubernetes集群的访问流量的变化趋势；

响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述第一节点小组中的全部节点进入休眠状态；所述第一节点小组和所述第二节点小组分别包括至少一个节点；

或者，

响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群上的部分应用调度至唤醒后的节点上。

2.根据权利要求1所述的Kubernetes集群的节能方法，其特征在于，所述确定Kubernetes集群的访问流量的变化趋势，包括：

采集部署在所述Kubernetes集群上的每个应用的历史访问数据；

根据所述每个应用的历史访问数据，确定所述Kubernetes集群的访问高峰期和访问低谷期的时间段。

3.根据权利要求1所述的Kubernetes集群的节能方法，其特征在于，所述确定Kubernetes集群的访问流量的变化趋势，包括：

采集所述Kubernetes集群中的每个节点的资源使用情况；

当所述Kubernetes集群中资源使用量超过预设第一阈值的节点数量超过预设第二阈值时，确定所述Kubernetes集群进入访问高峰期；

当所述Kubernetes集群中资源使用量低于预设第三阈值的节点数量超过预设第四阈值时，确定所述Kubernetes集群进入访问低谷期。

4.根据权利要求2或3所述的Kubernetes集群的节能方法，其特征在于，所述响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，包括：

根据所述Kubernetes集群的历史访问数据，确定所述Kubernetes集群的访问低谷期的访问量；

响应于所述Kubernetes集群进入访问低谷期，根据确定的所述访问低谷期的访问量，确定所述第一节点小组和所述第二节点小组对应的节点；

根据所述第二节点小组中的每个节点的资源使用情况，将部署在所述Kubernetes集群中的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上。

5.根据权利要求4所述的Kubernetes集群的节能方法，其特征在于，所述根据确定的所述访问低谷期的访问量，确定所述第一节点小组和所述第二节点小组对应的节点，包括：

根据所述访问低谷期的访问量和预设工作模式，确定在所述预设工作模式下，所述Kubernetes集群在所述访问低谷期对应的资源使用类型和资源使用量；

根据所述资源使用类型和资源使用量，确定所述Kubernetes集群上的全部应用在所述访问低谷期的部署方式，并将所述部署方式对应的全部节点作为所述第二节点小组。

6.根据权利要求2或3所述的Kubernetes集群的节能方法，其特征在于，在所述Kubernetes集群中的每个节点上设置有BMC硬件模块，

对应的，

所述响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，包括：

根据所述Kubernetes集群的历史访问数据，确定所述Kubernetes集群的访问高峰期的访问量；

在所述Kubernetes集群进入访问高峰期之前，根据确定的所述访问期的访问量，确定需要进行唤醒的节点，并通过所述BMC硬件模块提供的API接口对所述Kubernetes集群中的处于休眠状态的节点进行唤醒。

7.根据权利要求1所述的Kubernetes集群的节能方法，其特征在于，还包括：

采集所述Kubernetes集群中的每个节点的资源使用情况；

根据所述节点的资源使用情况，确定所述Kubernetes集群的资源使用情况；

当所述Kubernetes集群的空闲资源量超过预设第五阈值，或者所述Kubernetes集群的空闲资源比例超过预设第六阈值时，将部署在所述Kubernetes集群中资源使用量最小的节点上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述资源使用量最小的节点进入休眠状态；

当所述Kubernetes集群的空闲资源量低于预设第七阈值，或者所述Kubernetes集群的空闲资源比例低于预设第八阈值时，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群中资源使用量最大的应用调度至唤醒后的节点上。

8.一种Kubernetes集群的节能系统，其特征在于，包括：

趋势单元，配置为确定所述Kubernetes集群的访问流量的变化趋势；

节点调度单元，配置为响应于所述Kubernetes集群的访问流量处于下降趋势，将部署在所述Kubernetes集群的第一节点小组上的全部应用调度至所述Kubernetes集群中的第二节点小组上，并控制所述第一节点小组的全部节点进入休眠状态；所述第一节点小组和所述第二节点小组分别包括至少一个节点；或者，响应于所述Kubernetes集群的访问流量处于上升趋势，对所述Kubernetes集群中的处于休眠状态的至少一个节点进行唤醒，并将所述Kubernetes集群上的部分应用调度至唤醒后的节点上。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一所述的Kubernetes集群的节能方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的Kubernetes集群的节能方法。

Images