CN113849294B - 一种kubernetes pod扩缩容的系统及方法 - Google Patents

Abstract

本发明涉及一种kubernetes pod扩缩容的系统及方法，该系统包括在kubernetes集群中部署的API Server、资源调度控制器和自定义指标服务器，其中：API Server，用于获取自定义资源文件；资源调度控制器，用于根据自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；自定义指标服务器，用于通过API聚合的方式，暴露对应的实时进程指标；其中，自动弹性伸缩对象用于通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。本发明可以实现kubernetes环境下通过自定义指标实现pod水平自动扩缩容，并且部署和使用都比较简单，极大地减轻了运维负担。

Description

一种kubernetes pod扩缩容的系统及方法

技术领域

本发明涉及云计算技术领域，尤其涉及一种kubernetes pod扩缩容的系统及方法。

背景技术

近年来，随着云计算，云原生等领域的发展，越来越多的公司使用上了容器技术，提高了整体开发，运维水平和效率。其中由google主导开源的kubernetes容器编排工具目前处在主流地位，通过kubernetes可以实现容器应用的编排，自动部署，自动恢复以及自动扩缩容等功能。

pod是kubernetes上可以创建和部署的最小单位，pod代表着集群中运行的进程，进程的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，就依赖于kubernetes的pod水平自动扩缩容(Horizontal Pod Autoscaling)功能了。通过该功能，可以实现在业务高峰期，自动扩展pod数量，以提高应用整体负载能力，而在业务低谷期，能够自动缩减pod数量，以节省成本。但目前kubernetes核心库只能通过cpu和内存这两个监控指标来判断是否对pod进行水平扩缩容操作，而在一些复杂的业务场景下，需要通过一些其他的监控指标，来判断是否对pod进行水平扩缩容操作。因此，如何在kubernetes环境中通过自定义指标实现pod水平自动扩缩容成为亟待解决的问题。

发明内容

有鉴于此，有必要提供一种kubernetes pod扩缩容的系统及方法，用以克服现有技术中无法根据自定义指标对pod自动扩缩容的问题。

本发明提供一种kubernetes pod扩缩容的系统，包括在kubernetes集群中部署的API Server、资源调度控制器和自定义指标服务器，其中：

所述API Server，用于获取自定义资源文件；

所述资源调度控制器，用于根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；

所述自定义指标服务器，用于通过API聚合的方式，暴露对应的所述实时进程指标；

其中，所述自动弹性伸缩对象用于通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。

进一步地，还包括Prometheus组件，所述Prometheus组件用于通过pod的exporter端采集并存储所述实时进程指标。

本发明还提供了一种kubernetes pod扩缩容的方法，基于如上所述的kubernetespod扩缩容的系统，所述方法包括：

获取自定义资源文件；

根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；

通过API聚合的方式，暴露对应的所述实时进程指标；

通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。

进一步地，在所述获取自定义资源文件之前，还包括：

修改API Server的配置，开启对应的API聚合功能后，再重启所述API Server；

以kubernetes CRD的形式定义所述自定义资源文件，并将所述自定义文件注册至所述API Server；

在kubernetes集群中部署资源调度控制器、自定义指标服务器和Prometheus组件。

进一步地，所述根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标，包括：

根据所述自定义资源文件中的创建的自定义资源中的具体配置，生成所述自动弹性伸缩对象；

根据在所述自定义资源中具体配置的采集指标和采集频率，定期从Prometheus组件中查询节点中pod的所述实时进程指标。

进一步地，所述通过API聚合的方式，暴露对应的所述实时进程指标，包括：从所述资源调度控制器中获取所述实时进程指标，通过API聚合的方式，实现kubernetes custommetric API接口对外暴露对应的所述实时进程指标。

进一步地，所述通过暴露的所述实时进程指标，判断是否对pod进行扩缩容，包括：

定期查询所述kubernetes custom metric API接口，获取暴露的所述实时进程指标；

根据所述实时进程指标和具体配置中的预定义指标，判断是否对pod进行扩缩容，其中，所述自动弹性伸缩对象根据所述自定义资源文件的所述具体配置生成，所述具体配置包括至少一种所述预定义指标。

进一步地，所述根据所述实时进程指标和具体配置中的预定义指标，判断是否对pod进行扩缩容，包括：

根据所述实时进程指标和所述预定义指标的比较结果，判断是否对pod进行扩缩容。

进一步地，所述根据所述实时进程指标和所述预定义指标的比较结果，判断是否对pod进行扩缩容，包括：

若所述预定义指标为请求数，则根据所述预定义指标，确定每个pod在预设时间内的预设请求数；

根据所述实时进程指标，确定在所述预设时间内的实时请求总数；

根据所述预设请求数和所述实时请求总数，确定判断是否对pod进行扩缩容。

进一步地，所述根据所述预设请求数和所述实时请求总数，确定判断是否对pod进行扩缩容，包括：

根据所述实时请求总数和所述预设请求数之商，确定需求pod数目；

根据需求pod数目和当前实际的pod数目的比较结果，对节点中pod进行扩缩容操作。

与现有技术相比，本发明的有益效果包括：通过设置API Server，对自定义资源文件进行有效的获取和配置；通过设置资源调度控制器，一方面创建生成自动弹性伸缩对象，使其在后续进行判断是否扩缩容，另一方面，定期查询各个节点下的pod对应的实时进程指标；通过设置自定义指标服务器，采用API聚合的方式，使从资源调度控制器中获取的实时进程指标进行有效的暴露，便于自动弹性伸缩对象进行查询获取；通过生成的自动弹性伸缩对象，对自定义指标服务器中的暴露的实时进程指标进行有效的获取，并基于实时进程指标判断是否对pod进行扩缩容。

附图说明

图1为本发明提供的kubernetes pod扩缩容的系统一实施例的结构示意图；

图2为本发明提供的kubernetes pod扩缩容的系统一实施例的具体结构示意图；

图3为本发明提供的kubernetes pod扩缩容的方法一实施例的流程示意图；

图4为本发明提供的图3中步骤S1之前步骤一实施例的流程示意图；

图5为本发明提供的图3中步骤S2一实施例的流程示意图；

图6为本发明提供的图3中步骤S4一实施例的流程示意图；

图7为本发明提供的图6中步骤S602一实施例的流程示意图；

图8为本发明提供的图7中步骤S703一实施例的流程示意图；

图9为本发明提供的kubernetes pod扩缩容的装置一实施例的结构示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。

在本发明的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。此外，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本发明的描述中，提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，所描述的实施例可以与其它实施例相结合。

本发明提供了一种kubernetes pod扩缩容的系统及方法，充分考虑了自定义特征在多种业务场景下的适用性和灵活性，通过构建资源调度控制器和自定义指标服务器，对指标进行监测和判断，为进一步对pod进行扩缩容进行快速判断提供了新思路。以下分别进行详细说明：

本发明实施例提供了一种kubernetes pod扩缩容的系统，结合图1来看，图1为本发明提供的kubernetes pod扩缩容的系统一实施例的结构示意图，包括在kubernetes集群中部署的API Server101、资源调度控制器102和自定义指标服务器103，其中：

所述API Server101，用于获取自定义资源文件；

所述资源调度控制器102，用于根据所述自定义资源文件，生成自动弹性伸缩对象104，并定期查询节点中pod105的实时进程指标；

所述自定义指标服务器103，用于通过API聚合的方式，暴露对应的所述实时进程指标；

其中，所述自动弹性伸缩对象104用于通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。

在本发明实施例中，通过设置API Server，对自定义资源文件进行有效的获取和配置；通过设置资源调度控制器，一方面创建生成自动弹性伸缩对象，使其在后续进行判断是否扩缩容，另一方面，定期查询各个节点下的pod对应的实时进程指标；通过设置自定义指标服务器，又称为 metric-server，采用API聚合的方式，使从资源调度控制器中获取的实时进程指标进行有效的暴露，便于自动弹性伸缩对象进行查询获取；通过生成的自动弹性伸缩对象，对自定义指标服务器中的暴露的实时进程指标进行有效的获取，并基于实时进程指标判断是否对pod进行扩缩容。

作为优选的实施例，上述自定义资源文件包括自定义资源ScaledObject yaml文件。在本发明实施例中，创建自定义资源文件，用于定义监控何种指标，采集频率，水平扩缩容最大最小pod数目等信息，便于在不同业务场景下限定不同的监控指标、采集频率等信息，保证其灵活性。

作为优选的实施例，结合图2来看，图2为本发明提供的kubernetes pod扩缩容的系统一实施例的具体结构示意图，上述系统还包括Prometheus组件106，所述Prometheus组件106用于通过pod的exporter端采集并存储所述实时进程指标。

在本发明实施例中，通过设置Prometheus组件，对各个节点的pod对应的exporter端收集各种实时进程指标，并存储，以供其他组件查询这些实时进程指标。

本发明实施例提供了一种kubernetes pod扩缩容的方法，结合图3来看，图3为本发明提供的kubernetes pod扩缩容的方法一实施例的流程示意图，包括步骤S1至步骤S4，其中：

在步骤S1中，获取自定义资源文件；

在步骤S2中，根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；

在步骤S3中，通过API聚合的方式，暴露对应的所述实时进程指标；

在步骤S4中，通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。

在本发明实施例中，首先，对自定义资源文件进行有效的获取和配置，通过自定义资源文件确定不同业务场景下需要监控的指标信息和相应的阈值信息；然后，创建生成自动弹性伸缩对象，使其在后续进行判断是否扩缩容，并定期查询各个节点下的pod对应的实时进程指标；进而，采用API聚合的方式，使从资源调度控制器中获取的实时进程指标进行有效的暴露，便于自动弹性伸缩对象进行查询获取；最后，通过生成的自动弹性伸缩对象，对自定义指标服务器中的暴露的实时进程指标进行有效的获取，并基于实时进程指标判断是否对pod进行扩缩容。

需要说明的是，上述自定义资源文件主要用于定义不同应用场景下需要采集的实时进程指标以及采集的形式，包括诸如监控何种指标，采集频率，水平扩缩容最大最小pod数目等信息。以此，增加不同应用场景下的自定义的灵活性。

作为优选的实施例，结合图4来看，图4为本发明提供的图3中步骤S1之前步骤一实施例的流程示意图，包括步骤S401至步骤S403，其中：

在步骤S401中，修改API Server的配置，开启对应的API聚合功能后，再重启所述API Server；

在步骤S402中，以kubernetes CRD的形式定义所述自定义资源文件的形式，并将所述自定义文件注册至所述API Server

在步骤S403中，在kubernetes集群中部署资源调度控制器、自定义指标服务器和Prometheus组件。

在本发明实施例中，首先，对API Server进行配置修改，并启动其聚合功能，便于后续自动弹性伸缩对象通过接口，查询暴露对应的实时进程指标；然后，以kubernetes CRD的形式定义自定义资源，便于后续创建自定义资源文件；进而，在kubernetes集群中上述资源调度控制器、自定义指标服务器和Prometheus组件，保证各个组件利用自定义资源文件实现相应的功能。

需要说明的是，在步骤S402中，定义所述自定义资源文件的形式包括定义自定义资源文件的属性，版本，权限，角色绑定等信息，以便后续自定义资源文件的创建。利用自定义资源文件的定义形式，创建自定义资源文件，其中，包含了监控何种指标，采集频率，水平扩缩容最大最小pod数目等信息。

在本发明一个具体的实施例中，自定义资源文件为ScaledObject yaml文件，在创建ScaledObject yaml文件之前，定义ScaledObject yaml文件的语法约束，版本，所属API组等信息，进而，根据其定义的文件形式，基于实际的应用需求，创建一个ScaledObjectyaml文件，该文件满足上述定义的语法约束，并包括了应用需求中监控何种指标，采集频率，水平扩缩容最大最小pod数目等信息，定义了实际对各个pod需要监控的指标和需要监控的形式。

在本发明一个具体的实施例中，API Server优选为kubernetes API Server，对应的接口为kubernetes custom metric API接口。其中，自定义指标服务器是通过API聚合的方式扩展的kubernetes，如果不开启API聚合功能，自动弹性伸缩对象的控制器则无法通过kubernetes custom metric API接口访问到自定义指标。

作为优选的实施例，结合图5来看，图5为本发明提供的图3中步骤S2一实施例的流程示意图，包括步骤S501至步骤S502，其中：

在步骤S501中，根据所述自定义资源文件中的创建的自定义资源中的具体配置，生成所述自动弹性伸缩对象；

在步骤S502中，根据在所述自定义资源文件中具体配置的采集指标和采集频率，定期从Prometheus组件中查询节点中pod的所述实时进程指标。

在本发明实施例中，根据自定义资源文件具体配置的采集指标和采集频率等信息，生成对应的自动弹性伸缩对象，并利用资源调度控制器，基于定义资源文件中具体配置的采集指标和采集频率，定期从Prometheus组件中查询实时进程指标。

作为优选的实施例，上述步骤S3具体包括：从所述资源调度控制器中获取所述实时进程指标，通过API聚合的方式，实现kubernetes custom metric API接口对外暴露对应的所述实时进程指标。

在本发明实施例中，自定义指标服务器从资源调度控制器中获取所述实时进程指标，通过实现kubernetes custom metric API接口对外暴露自定义采集的实时进程指标。

作为优选的实施例，结合图6来看，图6为本发明提供的图3中步骤S4一实施例的流程示意图，包括步骤S601至步骤S602，其中：

在步骤S601中，定期查询所述kubernetes custom metric API接口，获取暴露的所述实时进程指标；

在步骤S602中，根据所述实时进程指标和具体配置中的预定义指标，判断是否对pod进行扩缩容，其中，所述自动弹性伸缩对象根据所述自定义资源文件的所述具体配置生成，所述具体配置包括至少一种所述预定义指标。

在本发明实施例中，创建的自动弹性伸缩对象，通过kubernetes custom metricAPI接口，定期查询自定义指标服务器中的暴露的所述实时进程指标，并根据创建时获得的自定义资源文件中的具体配置的预定义指标，进行相对应的判断。

作为优选的实施例，上述步骤S602具体包括：

根据所述实时进程指标和所述预定义指标的比较结果，判断是否对pod进行扩缩容。

在本发明实施例中，创建的自动弹性伸缩对象，根据实时进程指标和创建时就获取的预定义指标进行比较，判断此时的pod状态是否符合实际的应用需要。

作为优选的实施例，结合图7来看，图7为本发明提供的图6中步骤S602一实施例的流程示意图，包括步骤S701至步骤S703，其中：

在步骤S701中，若所述预定义指标为请求数，则根据所述预定义指标，确定每个pod在预设时间内的预设请求数；

在步骤S702中，根据所述实时进程指标，确定在所述预设时间内的实时请求总数；

在步骤S703中，根据所述预设请求数和所述实时请求总数，确定判断是否对pod进行扩缩容。

在本发明实施例中，当创建自动弹性伸缩对象时，自定义资源文件定义采集的指标为请求数和其对应的阈值（此时，对应的阈值即为预定义指标），根据预定义指标确定每个pod能达到的最大限度的预设请求数，并通过定期查询实时进程指标，确定实时请求总数，以此有效判断是否对pod进行扩缩容。

作为优选的实施例，结合图8来看，图8为本发明提供的图7中步骤S703一实施例的流程示意图，包括步骤S801至步骤S802，其中：

在步骤S801中，根据所述实时请求总数和所述预设请求数之商，确定需求pod数目；

在步骤S802中，根据需求pod数目和当前实际的pod数目的比较结果，对节点中pod进行扩缩容操作。

在本发明实施例中，根据实时请求总数和所述预设请求数之商，确定需求pod数目，在判断当前的pod数目是否满足需求，进而确定是否扩缩容操作。

在本发明一个具体的实施例中，ScaledObject yaml文件定义监控http_requests_total这个指标，计算sum(rate(http_requests_total[1m]))，也就是每秒的请求数，并设定了对应的阈值，即预定义指标为1000，也就是平均每个pod每秒的请求数要小于等于1000，资源调度控制器基于ScaledObject yaml文件，定期从Prometheus组件中查询监控的每秒的实时请求总数，并创建自动弹性伸缩对象接收实时请求总数和预设请求数，进行对比，判断是否对pod进行扩缩容操作。假设每秒的实时请求总数为3300，那么，总共的需求pod数目会有4个pod，假设每秒请求总数为 11000，那么，总共的需求pod数目将会有11个pod，此时的pod数目若小于需求pod数目，则进行扩容操作，若大于需求pod数目，则进行缩容操作，可以实现在业务高峰期，自动扩展pod数量，以提高应用整体负载能力，而在业务低谷期，能够自动缩减pod数量，以节省成本。

下面以一个具体的应用例，更好地说明本发明的技术方案：

在该应用场景下，API Server为kubernetes API Server，资源调度控制器为phpa-controller组件，自定义指标服务器为phpa-metric-server组件，自动弹性伸缩对象为kubernetes horizontal pod autoscaler对象，自定义资源文件为ScaledObject yaml文件，判断是否进行扩缩容操作的具体流程如下：

第一步，修改kubernetes API Server的配置，开启API聚合功能，并重启APIServer；

第二步，定义自定义资源ScaledObject yaml文件，并注册到API Server。该文件描述了自定义资源ScaledObject的语法约束，版本，所属API组等信息；

第三步，在kubernetes集群中部署phpa-controller组件和phpa-metric-server组件。其中，phpa-controller组件通过获取自定义资源ScaledObject中配置的采集指标，采集频率，水平扩缩容最大最小pod数目等信息，定期从prometheus中采集对应的监控指标数据；而phpa-metric-server通过API聚合的方式实现了kubernetes custom metric API接口，从而使得horizontal pod autoscaler通过该API路径获取到自定义监控指标的值；

第四步，在kubernetes集群中部署prometheus组件，prometheus通过pod对应的exporter收集各种监控指标，并存储，以供其他组件查询这些指标；

第五步，创建自定义资源ScaledObject yaml文件，该文件定义了监控何种指标，采集频率，水平扩缩容最大最小pod数目等信息；

第六步，phpa-controller通过kubernetes API Server获取到自定义资源ScaledObject的具体配置，并根据这些配置生成kubernetes horizontal pod autoscaler对象；

第七步，phpa-controller通过自定义资源ScaledObject中配置的采集指标和采集频率等信息，定期从prometheus中查询这些监控指标的数值；

第八步，phpa-metric-server通过实现kubernetes custom metric API接口对外暴露自定义指标，其底层正是通过phpa-controller获取到相应指标的最新数值；

第九步，horizontal pod autoscaler对象的控制器定期查询kubernetes custommetric API接口，获取自定义监控指标的数值，并判断是否需要对相应pod执行水平扩缩容操作；

第十步，kubernetes根据horizontal pod autoscaler对象的控制器的返回结果对具体pod执行水平扩缩容操作。

本发明实施例还提供了一种kubernetes pod扩缩容的装置，结合图9来看，图9为本发明提供的kubernetes pod扩缩容的装置一实施例的结构示意图，kubernetes pod扩缩容的装置900包括：

获取单元901，用于获取自定义资源文件；

处理单元902，用于根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；还用于通过API聚合的方式，暴露对应的所述实时进程指标；

判断单元903，用于通过暴露的所述实时进程指标，判断是否对pod进行扩缩容。

kubernetes pod扩缩容的装置的各个单元的更具体实现方式可以参见对于本kubernetes pod扩缩容的方法的描述，且具有与之相似的有益效果，在此不再赘述。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时，实现如上所述的kubernetes pod扩缩容的方法。

一般来说，用于实现本发明方法的计算机指令的可以采用一个或多个计算机可读的存储介质的任意组合来承载。非临时性计算机可读存储介质可以包括任何计算机可读介质，除了临时性地传播中的信号本身。

计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器（RAM）、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言，特别是可以使用适于神经网络计算的Python语言和基于TensorFlow、PyTorch等平台框架。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。

本发明实施例还提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，实现如上所述的kubernetes pod扩缩容的方法。

根据本发明上述实施例提供的计算机可读存储介质和计算设备，可以参照根据本发明实现如上所述的kubernetes pod扩缩容的方法具体描述的内容实现，并具有与如上所述的kubernetes pod扩缩容的方法类似的有益效果，在此不再赘述。

本发明公开了一种kubernetes pod扩缩容的系统及方法，通过设置API Server，对自定义资源文件进行有效的获取和配置；通过设置资源调度控制器，一方面创建生成自动弹性伸缩对象，使其在后续进行判断是否扩缩容，另一方面，定期查询各个节点下的pod对应的实时进程指标；通过设置自定义指标服务器，采用API聚合的方式，使从资源调度控制器中获取的实时进程指标进行有效的暴露，便于自动弹性伸缩对象进行查询获取；通过生成的自动弹性伸缩对象，对自定义指标服务器中的暴露的实时进程指标进行有效的获取，并基于实时进程指标判断是否对pod进行扩缩容。

本发明技术方案，可以实现kubernetes环境下通过自定义指标实现pod水平自动扩缩容，并且部署和使用都比较简单，极大地减轻了运维负担。在不同的应用场景，可以通过自定义的监测指标，实现在业务高峰期，自动扩展pod数量，以提高应用整体负载能力，而在业务低谷期，能够自动缩减pod数量，以节省成本，保证了灵活性。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (8)

1.一种kubernetes pod扩缩容的系统，其特征在于，包括在kubernetes集群中部署的API Server、资源调度控制器和自定义指标服务器，其中：

所述API Server，用于获取自定义资源文件；

所述资源调度控制器，用于根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；

所述自定义指标服务器，用于通过API聚合的方式，暴露对应的所述实时进程指标；

其中，所述自动弹性伸缩对象用于通过暴露的所述实时进程指标，判断是否对pod进行扩缩容；

其中，所述API Server、所述资源调度控制器和所述自定义指标服务器的构建过程包括：

修改所述API Server的配置，开启对应的API聚合功能后，再重启所述API Server；

以kubernetes CRD 的形式定义所述自定义资源文件，并将所述自定义资源文件注册至所述API Server；

在kubernetes集群中部署资源调度控制器、自定义指标服务器和Prometheus组件；

其中，所述资源调度控制器，具体用于：

根据所述自定义资源文件中的创建的自定义资源中的具体配置，生成所述自动弹性伸缩对象；

根据在所述自定义资源中具体配置的采集指标和采集频率，定期从Prometheus组件中查询节点中pod的所述实时进程指标。

2.根据权利要求1所述的kubernetes pod扩缩容的系统，其特征在于，还包括Prometheus组件，所述Prometheus组件用于通过pod的exporter端采集并存储所述实时进程指标。

3.一种kubernetes pod扩缩容的方法，其特征在于，基于根据权利要求1至2任一项所述的kubernetes pod扩缩容的系统，所述方法包括：

获取自定义资源文件；

根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标；

通过API聚合的方式，暴露对应的所述实时进程指标；

通过暴露的所述实时进程指标，判断是否对pod进行扩缩容；

其中，在所述获取自定义资源文件之前，还包括：

修改API Server的配置，开启对应的API聚合功能后，再重启所述API Server；

以kubernetes CRD 的形式定义所述自定义资源，并将所述自定义资源文件注册至所述API Server；

在kubernetes集群中部署资源调度控制器、自定义指标服务器和Prometheus组件；

其中，所述根据所述自定义资源文件，生成自动弹性伸缩对象，并定期查询节点中pod的实时进程指标，包括：

根据所述自定义资源文件中的创建的自定义资源中的具体配置，生成所述自动弹性伸缩对象；

根据在所述自定义资源中具体配置的采集指标和采集频率，定期从Prometheus组件中查询节点中pod的所述实时进程指标。

4.根据权利要求3所述的kubernetes pod扩缩容的方法，其特征在于，所述通过API聚合的方式，暴露对应的所述实时进程指标，包括：从所述资源调度控制器中获取所述实时进程指标，通过API聚合的方式，实现kubernetes custom metric API接口对外暴露对应的所述实时进程指标。

5.根据权利要求4所述的kubernetes pod扩缩容的方法，其特征在于，所述通过暴露的所述实时进程指标，判断是否对pod进行扩缩容，包括：

定期查询所述kubernetes custom metric API接口，获取暴露的所述实时进程指标；

根据所述实时进程指标和具体配置中的预定义指标，判断是否对pod进行扩缩容，其中，所述自动弹性伸缩对象根据所述自定义资源文件的所述具体配置生成，所述具体配置包括至少一种所述预定义指标。

6.根据权利要求5所述的kubernetes pod扩缩容的方法，其特征在于，所述根据所述实时进程指标和具体配置中的预定义指标，判断是否对pod进行扩缩容，包括：

根据所述实时进程指标和所述预定义指标的比较结果，判断是否对pod进行扩缩容。

7.根据权利要求6所述的kubernetes pod扩缩容的方法，其特征在于，所述根据所述实时进程指标和所述预定义指标的比较结果，判断是否对pod进行扩缩容，包括：

若所述预定义指标为请求数，则根据所述预定义指标，确定每个pod在预设时间内的预设请求数；

根据所述实时进程指标，确定在所述预设时间内的实时请求总数；

根据所述预设请求数和所述实时请求总数，确定判断是否对pod进行扩缩容。

8.根据权利要求7所述的kubernetes pod扩缩容的方法，其特征在于，所述根据所述预设请求数和所述实时请求总数，确定判断是否对pod进行扩缩容，包括：

根据所述实时请求总数和所述预设请求数之商，确定需求pod数目；

根据需求pod数目和当前实际的pod数目的比较结果，对节点中pod进行扩缩容操作。

Images