一种面向服务管理平台Kubernetes的服务管理方法及管理平台

技术领域

本发明涉及云计算服务管理技术领域，尤其涉及到一种面向服务管理平台Kubernetes的服务管理方法及管理平台Kubernetes。

背景技术

Kubernetes是当前流行的服务管理平台，Kubernetes中的节点是Kubernetes中最小的计算硬件单元，它是集群中单个机器的表示。Kubernetes不直接运行容器，而是将一个或多个容器封装到Pod中，服务管理技术作为该平台的关键技术，其目标是在系统中合理部署Pod并将节点资源分配给各类Pod进行使用。因此，服务管理技术对于系统承载的服务质量具有决定性作用。

Kubernetes的原生服务管理系统不能很好保证服务质量。例如：在服务部署时只考虑了CPU和内存资源，而没有考虑网络带宽等其他资源需求；其次，调度系统通常会忽略服务对特定指标的要求(例如，低延迟要求)；系统仅根据内存使用情况来判断节点的负载是否过高，并且在节点负载过高时，仅采取关闭资源使用较多的Pod然后对其进行重新部署的措施；此外，当服务质量下降时，系统也没有措施来控制服务的副本数量。

可见，现有的Kubernetes，在服务部署时局限于CPU和内存资源的影响，不能根据服务资源需求情况、节点资源、节点负载情况等多种因素，确保在满足应用需求的同时将Pod分配到最优节点，从而无法实现服务的优化部署。服务运行过程不能根据各因素的实际变化情况来调整服务质量、节点压力及系统资源消耗的问题。

发明内容

本发明实施例提供了一种面向服务管理平台Kubernetes的服务管理方法及管理平台Kubernetes，以至少解决现有的Kubernetes无法实现服务的优化部署的问题。

本发明第一个方面，提供了一种面向服务管理平台Kubernetes的服务管理方法，包括：

确定各节点配置的服务资源及各节点中每种服务资源被各pod使用的资源使用信息，所述服务资源的类型包括CPU、内存及网络带宽；

基于服务运行流程的运行需求，分别确定各pod需对节点中每种服务资源进行占用的第一资源占用信息；

根据所述服务资源的类型、所述资源使用信息及所述第一资源占用信息，采用层次分析法确定目标节点；

将各Pod部署到所述目标节点实现服务部署后，进入所述服务运行流程。

可选的，所述资源使用信息为节点中每种服务资源未被各pod占用的资源空闲占用信息时，所述根据所述服务资源的类型、所述资源使用信息及所述第一资源占用信息，采用层次分析法确定目标节点，包括：

根据各pod需对节点中每种服务资源进行占用的第一资源占用信息，确定各节点中每种服务资源之间的相对重要性参数，所述相对重要性参数为不同服务资源的第一资源占用信息之比；

根据所述服务资源的类型和所述相对重要性参数，构建第一指标层判断矩阵，以获得每种服务资源对应的资源重要性权重；

根据各节点中每种服务资源的资源空闲占用信息，构建第一方案层判断矩阵，以获得各节点中每种服务资源的空闲占用权重；

根据所述资源重要性权重和所述空闲占用权重，构建第一目标层权重矩阵，以获得各节点的目标权重值，并将目标权重值最大的节点确定为所述目标节点。

可选的，在所述服务运行流程，所述服务管理方法还包括：

实时监控并存储各pod在所述服务运行流程对节点中每种服务资源进行占用的第二资源占用信息，当需将所述pod部署至下次服务部署之前确定的所述目标节点之前，根据所述第二资源占用信息对所述第一指标层判断矩阵进行动态更新。

可选的，所述Pod的种类包括资源限制型Pod和非资源限制型Pod；则所述资源使用信息为节点中每种服务资源被各pod占用的资源被占用信息时，在所述服务运行流程，所述服务管理方法还包括：

在预设的时间间隔内，不断获取服务的SLA违反信息，同时，根据各节点中每种服务资源的所述资源被占用信息不断获取各节点的负载信息；

根据所述Pod的种类、所述负载信息、所述SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

可选的，所述服务管理方法还包括：

确定所述资源被占用信息的预警上限值；

则所述根据各节点中每种服务资源的所述资源被占用信息不断获取各节点的负载信息，包括：

在预设的时间间隔内依次遍历各节点中每种服务资源的所述资源被占用信息，并判断各节点中是否有服务资源的所述资源被占用信息大于所述预警上限值，若是，则将存在所述资源被占用信息大于所述预警上限值的节点确定为负载过重的节点。

可选的，所述确定是否需对节点上的Pod进行迁移或副本伸缩处理之前，还确定所述SLA违反信息的额定违反阈值；则：

所述根据所述Pod的种类、所述负载信息、所述SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，包括：

当服务的所述SLA违反信息超过所述额定违反阈值，且该服务所在的节点为负载过重的节点，则根据所述服务资源的类型、节点中每种所述服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod；

根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

可选的，所述根据所述服务资源的类型、节点中每种所述服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod，包括：

根据节点中每种服务资源的资源被占用信息确定各服务资源之间的资源紧缺度参数，所述资源紧缺度参数为各节点中不同服务资源的资源被占用信息之比；

根据所述服务资源的类型和所述资源紧缺度参数，构建第二指标层判断矩阵，以获得节点中每种服务资源对应的资源紧缺度权重；

根据各pod对节点中每种服务资源的第二资源占用信息，构建第二方案层判断矩阵，以获得各pod的资源占用权重；

根据所述资源紧缺度权重和所述资源占用权重，构建第二目标层权重，以获得各pod的目标权重值，并将目标权重值最大的pod确定为所述待处理的pod。

可选的，所述服务管理方法还包括：

确定待处理的pod对节点中每种服务资源的第二资源占用信息的占用预警值；则：

所述根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，包括：

若待处理的pod为非资源限制型pod，且其对节点中至少一种服务资源的第二资源占用信息大于所述占用预警值，则将该待处理的pod进行副本扩容处理，并将扩容的副本部署至下次服务部署之前确定的所述目标节点中。

本发明第二个方面，提供了一种服务管理平台Kubernetes，包括：

第一确定模块，用于确定各节点配置的服务资源及各节点中每种服务资源被各pod使用的资源使用信息，所述服务资源的类型至少包括CPU、内存及网络带宽；

第二确定模块，用于基于服务运行流程的运行需求，分别确定各pod需对节点中每种服务资源进行占用的第一资源占用信息；

节点筛选模块，用于根据所述服务资源的类型、所述资源使用信息及所述第一资源占用信息，采用层次分析法确定目标节点；

部署模块，用于将各Pod部署到所述目标节点实现服务部署后，进入所述服务运行流程。

本发明实施例的有益效果为：

首先，本发明利用层次分析法对Pod进行优化服务部署时，充分考虑了节点资源的使用情况和Pod对于各种资源的需求情况，根据资源的重要性来确定各类资源权重并最终筛选出目标节点。资源权重矩阵在系统运行过程中可以动态更新，进而更加合理地对Pod进行部署。其次，在服务运行过程中最大限度的保障了服务的质量，从Pod迁移和Pod副本扩容两方面缓解节点负载过重，提升服务质量，还能在当前节点负载过轻时通过适当减少服务的副本数量以减少资源浪费。因此，本发明实施例提供的服务管理方法使得Kubernetes在服务部署时能根据服务资源需求情况、节点资源、节点负载情况等多种因素，确保在满足应用需求的同时将Pod分配到最优节点，实现服务的优化部署后，在服务运行过程持续监控服务质量、节点资源使用情况等因素，从而根据各因素的实际变化情况来合理地对Pod进行迁移或副本伸缩控制，来达到提升服务质量、缓解节点压力并减少系统资源消耗的目的。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明第一实施例提供的一种面向服务管理平台Kubernetes的服务管理方法的流程示意图；

图2为图1在本发明第一实施例中实施步骤S13的流程示意图；

图3为本发明第一实施例提供的服务管理方法在服务运行流程实施的流程示意图；

图4为图3在本发明第一实施例中实施步骤S22的流程示意图；

图5为图4在本发明第一实施例中实施步骤S221筛选待处理的pod的流程示意图；

图6为本发明第二实施例提供的一种服务管理平台Kubernetes的结构示意图；

图7为本发明第三实施例提供的一种面向服务管理平台Kubernetes的服务管理方法的流程示意图；

图8为本发明第三实施例中采用层次分析法确定目标节点的建模结构示意图；

图9为本发明第三实施例中采用层次分析法筛选待处理的pod的建模结构示意图；

图10为本发明第三实施例提供的服务管理平台的结构模型图；

图11为本发明第三实施例基于面向服务管理平台Kubernetes的服务管理方法提供的自定义调度结构图；

图12为本发明第三实施例提供的服务管理平台Kubernetes配置的Qos控制器的结构示意图。

图中：1-第一确定模块，2-第二确定模块，3-节点筛选模块，4-部署模块，5-Pod监管模块，6-资源运算模块，61-pod筛选模块，62-资源调度模块，7-运行监管模块。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在本发明第一实施例中，提供了一种面向服务管理平台Kubernetes的服务管理方法，包括如下步骤的方法：

步骤S11：确定各节点配置的服务资源及各节点中每种服务资源被各pod使用的资源使用信息，服务资源的类型包括CPU、内存及网络带宽，以确保服务部署时，除考虑CPU和内存资源的需求，还能综合考虑网络带宽资源的影响，更好的保证服务质量；

步骤S12：基于服务运行流程的运行需求，分别确定各pod需对节点中每种服务资源进行占用的第一资源占用信息，即Pod的资源需求情况；

步骤S13：根据服务资源的类型、资源使用信息及第一资源占用信息，采用层次分析法确定目标节点；

步骤S14：将各Pod部署到目标节点实现服务部署后，进入服务运行流程。

由此，本发明通过上述服务管理流程，使得Kubernetes能够根据服务资源需求情况、节点资源等因素，确保在满足应用需求的同时将Pod分配到最优节点，实现服务的优化部署，提升服务质量。

在本发明实施例中，当资源使用信息为节点中每种服务资源未被各pod占用的资源空闲占用信息时，请参见图2，步骤S13中，根据服务资源的类型、资源使用信息及第一资源占用信息，采用层次分析法确定目标节点，具体包括如下步骤的方法：

步骤S131：根据各pod需对节点中每种服务资源进行占用的第一资源占用信息，确定各节点中每种服务资源之间的相对重要性参数，相对重要性参数为不同服务资源的第一资源占用信息之比，例如，由于某个Pod的CPU资源需求相对于内存重要性略高，则相对重要性参数值可设为2；

步骤S132：根据服务资源的类型和相对重要性参数，构建第一指标层判断矩阵，以获得每种服务资源对应的资源重要性权重；

步骤S133：根据各节点中每种服务资源的资源空闲占用信息，构建第一方案层判断矩阵，以获得各节点中每种服务资源的空闲占用权重；

步骤S134：根据资源重要性权重和空闲占用权重，构建第一目标层权重矩阵，以获得各节点的目标权重值，并将目标权重值最大的节点确定为目标节点。

具体地，在本发明实施例的步骤S132中，构建第一指标层判断矩阵的横纵坐标均设置为各个服务资源，矩阵元素取值为横坐标代表资源相对于纵坐标代表资源的相对重要性参数。然后对第一指标层判断矩阵求取最大特征向量，并进行归一化处理后，得到每一种服务资源对应的资源重要性权重。

在本发明一优选实施例中，步骤S133中，根据各节点中每种服务资源的资源空闲占用信息，构建第一方案层判断矩阵时，将每一种服务资源对应一个矩阵D，如：CPU资源的方案层矩阵横纵坐标为各个节点(Node)，矩阵元素Dij为节点Nodei的CPU空闲占用率/Nodej的CPU空闲占用率，然后对CPU资源的方案层判断矩阵求取最大特征向量，并进行归一化处理得到各个节点Node中CPU空闲占用的权重值(即CPU空闲占用权重)。同理构建内存矩阵、网络带宽矩阵(包括上行带宽矩阵和下行带宽矩阵)，并求取各个Node对不同服务资源的权空闲占用权重。

在步骤S134中构建第一目标权重矩阵，求取各节点权重值时，按如下公式求取：节点Nodei权重值＝CPU资源重要性权重*NodeiCPU空闲占用权重+内存资源重要性权重*Nodei内存空闲占用权重+上行带宽资源重要性权重*Nodei上行带宽空闲占用权重+下行带宽资源重要性权重*Nodei下行带宽空闲占用权重，其中*号表示求乘积。由此类推得到所有节点的目标权重值，然后选取得分最大的节点Node(即目标权重值最大的节点)作为目标节点，将各个Pod部署到该目标节点，实现服务的优化部署。在常规的层次分析法中构建比较矩阵时需要进行一致性判断，但本发明实施例由于采用了真实数据进行对比故不会出现一致性问题。

在本发明一优选实施例中，在服务运行流程，服务管理方法还包括如下步骤：实时监控并存储各pod在服务运行流程对节点中每种服务资源进行占用的第二资源占用信息，当需将pod部署至下次服务部署之前确定的目标节点之前，根据第二资源占用信息对第一指标层判断矩阵进行动态更新。即在系统运行过程中对Pod资源使用情况进行记录，实时监控Pod的资源占用数据(即第二资源占用信息)，利用Kubernetes原有数据库Etcd对Pod资源占用数据进行存储。当后续此类Pod需要调度时，根据该Pod的最新资源使用情况对步骤S132中的第一指标层判断矩阵进行动态更新，进而更加合理地对Pod进行部署。例如：记录数据中的最新资源使用情况显示该Pod的CPU占用30％(量化为3)，内存占用20％(量化为2)，则第一指标层判断矩阵中CPU对内存的相对重要性参数为3/2，对3/2向上取整为2。

在本发明实施例中，Pod的种类包括资源限制型Pod和非资源限制型Pod。则资源使用信息为节点中每种服务资源被各pod占用的资源被占用信息时，请参见图3，在服务运行流程，服务管理方法还包括：

步骤S21：在预设的时间间隔内，不断获取服务的SLA违反信息，同时，根据各节点中每种服务资源的资源被占用信息不断获取各节点的负载信息；

步骤S22：根据Pod的种类、负载信息、SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

可选的，本发明实施例提供的服务管理方法还包括确定资源被占用信息的预警上限值；则步骤S21中，根据各节点中每种服务资源的资源被占用信息不断获取各节点的负载信息，具体包括：

在预设的时间间隔内依次遍历各节点中每种服务资源的资源被占用信息，并判断各节点中是否有服务资源的资源被占用信息大于预警上限值，若是，则将存在资源被占用信息大于预警上限值的节点确定为负载过重的节点。如，把预警上限值设置为90％(该数值可根据实际运行情况进行调整，本发明在此不做唯一限定)，若有节点出现资源被占用信息大于90％，则该节点被视为负载过重。

在本发明一可选实施例中，步骤S22确定是否需对节点上的Pod进行迁移或副本伸缩处理之前，还确定SLA违反信息的额定违反阈值；则，请参见图4，步骤S22根据Pod的种类、负载信息、SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，具体包括：

步骤S221：当服务的SLA违反信息超过额定违反阈值，且该服务所在的节点为负载过重的节点，则根据服务资源的类型、节点中每种服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod；

步骤S222：根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

请参见图5，步骤S221中根据服务资源的类型、节点中每种服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod，具体包括：

步骤S2211：根据节点中每种服务资源的资源被占用信息确定各服务资源之间的资源紧缺度参数，资源紧缺度参数为各节点中不同服务资源的资源被占用信息之比；

步骤S2212：根据服务资源的类型和资源紧缺度参数，构建第二指标层判断矩阵，以获得节点中每种服务资源对应的资源紧缺度权重；

步骤S2213：根据各pod对节点中每种服务资源的第二资源占用信息，构建第二方案层判断矩阵，以获得各pod对节点中每种服务资源的资源占用权重；

步骤S2214：根据资源紧缺度权重和资源占用权重，构建第二目标层权重，以获得各pod的目标权重值，并将目标权重值最大的pod确定为待处理的pod。

具体的，资源被占用信息为节点中每种服务资源的资源被占用率时，参照筛选目标节点时矩阵的设置方法，步骤S2212中，第二指标层判断矩阵横纵坐标均设置为节点Node中的各类服务资源，矩阵中各元素为对应节点Node之间的资源占用率之比。第二方案层判断矩阵横纵坐标为各个Pod，各矩阵元素值为对应Pod之间的该资源的使用率之比(即第二资源占用信息之比),资源紧缺度权重和资源占用权重均为分别求取各自判断矩阵的最大特征向量并进行归一化处理得到，最后计算出第二目标矩阵，根据加权和选出需要进行处理的Pod，Pod的权重计算公式参照在步骤S134中构建第一目标权重矩阵，求取各节点权重值时的公式，如Podi目标权重值＝CPU资源紧缺度权重*PodiCPU资源占用权重+内存资源紧缺度权重*Podi内存资源占用权重+上行带宽资源紧缺度权重*Podi上行带宽资源占用权重+下行带宽资源紧缺度权重*Podi下行带宽资源占用权重，其中*号表示求乘积。由此类推得到所有pod的目标权重值，然后选取得分最大的pod(即目标权重值最大的pod)作为待处理的pod，由此选择出资源占比较大的Pod，然后通过对其进行迁移或者副本扩容操作来缓解负载过重的节点Node的压力。

在本发明实施例中，服务管理方法还包括确定待处理的pod对节点中每种服务资源的第二资源占用信息的占用预警值；则步骤S222中根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，包括：若待处理的pod为非资源限制型pod，且其对节点中至少一种服务资源的第二资源占用信息大于占用预警值，则将该待处理的pod进行副本扩容处理，并将扩容的副本部署至下次服务部署之前确定的目标节点中，持续优化部署，提升服务质量。

在本发明可选实施例中，步骤S222根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，还包括：

若待处理的pod为资源限制型pod，或待处理的pod为非资源限制型pod且其对节点中的每种服务资源的第二资源占用信息均小于占用预警值，则将待处理的pod关闭并生成pod停止信息，然后根据pod停止信息将相应的待处理的pod部署至下次服务部署之前确定的目标节点中。

当Pod的种类为资源限制型Pod，在确定资源被占用信息的预警上限值时，还确定资源被占用信息的第一预警下限值，在预设的时间间隔内依次遍历各节点中每种服务资源的所述资源被占用信息后，若判断出各节点中没有服务资源的所述资源被占用信息大于预警上限值，则判断各节点中是否有服务资源的资源被占用信息小于第一预警下限值，若是，则将存在资源被占用信息小于第一预警下限值的节点确定为负载过轻的节点。

在步骤S22中，根据Pod的种类、负载信息、SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理，还包括：当服务的SLA违反信息超过额定违反阈值，但该服务所在的节点不是负载过重也不是负载过轻的节点，则对该服务的资源限制型pod进行副本扩容处理。针对资源限制型Pod由于初始定义时对此类Pod限制了资源使用数量，当用户请求量暴增时可能由于分配的资源不够导致服务质量变低，此时系统会对该Pod所在的服务进行扩容处理，使副本数量加一，为该服务分配更多的资源来提高服务质量。

其次，确定资源被占用信息的第一预警下限值时，还确定资源被占用信息的第二预警下限值，且第二预警下限值大于第一预警下限值。则步骤S22中确定是否需对节点上的Pod进行迁移或副本伸缩处理还包括：

若资源限制型Pod所在服务的节点为负载过轻的节点，则对节点上的Pod进行副本缩容处理，并确保缩容处理后服务资源的资源被占用信息小于第二预警下限值。假设服务1有四个Pod副本，每个副本的内存分配为400m，但是四个副本在30分钟内实际使用的平均内存皆为200m，此时会有大量内存资源空闲(即，第一预警下限值在本发明一实施例中可确定为50％)，但是其它服务又不能使用这些资源从而导致资源的浪费，此时可考虑对服务的副本进行缩容，若缩容后的资源使用：200*4/(400*(4-1))<80％(即第二预警下限值),即可对Pod副本数量进行减一实现缩容处理。也就是说，服务出现轻载时，减少其副本数量，尽量保证节点资源使用率在80％左右以减少资源浪费。

本发明实施例利用层次分析法对Pod进行优化服务部署时，充分考虑了节点资源的使用情况和Pod对于各种资源的需求情况，根据资源的重要性来确定各类资源权重并最终筛选出目标节点。资源权重矩阵在系统运行过程中可以动态更新，进而更加合理地对Pod进行部署。其次，在服务运行过程中最大限度的保障了服务的质量，从Pod迁移和Pod副本扩容两方面缓解节点负载过重，提升服务质量，还能在当前节点负载过轻时通过适当减少服务的副本数量以减少资源浪费。因此，本发明实施例提供的服务管理方法使得Kubernetes在服务部署时能根据服务资源需求情况、节点资源、节点负载情况等多种因素，确保在满足应用需求的同时将Pod分配到最优节点，实现服务的优化部署后，在服务运行过程持续监控服务质量、节点资源使用情况等因素，从而根据各因素的实际变化情况来合理地对Pod进行迁移或副本伸缩控制，来达到提升服务质量、缓解节点压力并减少系统资源消耗的目的。

请参见图6，在本发明第二实施例中，提供了一种服务管理平台Kubernetes，包括：

第一确定模块1，用于确定各节点配置的服务资源及各节点中每种服务资源被各pod使用的资源使用信息，服务资源的类型至少包括CPU、内存及网络带宽；

第二确定模块2，用于基于服务运行流程的运行需求，分别确定各pod需对节点中每种服务资源进行占用的第一资源占用信息；

节点筛选模块3，用于根据服务资源的类型、资源使用信息及第一资源占用信息，采用层次分析法确定目标节点；

部署模块4，用于将各Pod部署到目标节点实现服务部署后，进入服务运行流程。

当资源使用信息为节点中每种服务资源未被各pod占用的资源空闲占用信息时，节点筛选模块3根据服务资源的类型、资源使用信息及第一资源占用信息，采用层次分析法确定目标节点时，具体执行如下方法的步骤：

步骤S131：根据各pod需对节点中每种服务资源进行占用的第一资源占用信息，确定各节点中每种服务资源之间的相对重要性参数，相对重要性参数为不同服务资源的第一资源占用信息之比，例如，由于某个Pod的CPU资源需求相对于内存重要性略高，则相对重要性参数值可设为2；

步骤S132：根据服务资源的类型和相对重要性参数，构建第一指标层判断矩阵，以获得每种服务资源对应的资源重要性权重；

步骤S133：根据各节点中每种服务资源的资源空闲占用信息，构建第一方案层判断矩阵，以获得各节点中每种服务资源的空闲占用权重；

步骤S134：根据资源重要性权重和空闲占用权重，构建第一目标层权重矩阵，以获得各节点的目标权重值，并将目标权重值最大的节点确定为目标节点。

服务管理平台Kubernetes还包括：

pod监管模块5，用于实时监控并存储各pod在服务运行流程对节点中每种服务资源进行占用的第二资源占用信息，当需将pod部署至下次服务部署之前确定的目标节点之前，根据第二资源占用信息对节点筛选模块3构建的第一指标层判断矩阵进行动态更新。

Pod的种类包括资源限制型Pod和非资源限制型Pod；则资源使用信息为节点中每种服务资源被各pod占用的资源被占用信息时，服务管理平台Kubernetes还包括：

运行监管模块7，用于在预设的时间间隔内，不断获取服务的SLA违反信息，同时，根据各节点中每种服务资源的资源被占用信息不断获取各节点的负载信息；

资源运算模块6，用于根据Pod的种类、负载信息、SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

所述第一确定模块1还用于确定资源被占用信息的预警上限值，则运行监管模块7根据各节点中每种服务资源的资源被占用信息不断获取各节点的负载信息时，具体执行如下方法的步骤：在预设的时间间隔内依次遍历各节点中每种服务资源的资源被占用信息，并判断各节点中是否有服务资源的资源被占用信息大于第一确定模块1确定的预警上限值，若是，则将存在资源被占用信息大于预警上限值的节点确定为负载过重的节点。

资源运算模块6确定是否需对节点上的Pod进行迁移或副本伸缩处理之前，还确定SLA违反信息的额定违反阈值；则资源运算模块6包括：

pod筛选模块61，用于当服务的SLA违反信息超过额定违反阈值，且该服务所在的节点为负载过重的节点，则根据服务资源的类型、节点中每种服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod。

资源调度模块62，用于根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理。

pod筛选模块61根据服务资源的类型、节点中每种服务资源的资源被占用信息及各pod对节点中每种服务资源的第二资源占用信息，采用层次分析法筛选出待处理的pod时，具体执行如下方法的步骤：

步骤S2211：根据节点中每种服务资源的资源被占用信息确定各服务资源之间的资源紧缺度参数，资源紧缺度参数为各节点中不同服务资源的资源被占用信息之比；

步骤S2212：根据服务资源的类型和资源紧缺度参数，构建第二指标层判断矩阵，以获得节点中每种服务资源对应的资源紧缺度权重；

步骤S2213：根据各pod对节点中每种服务资源的第二资源占用信息，构建第二方案层判断矩阵，以获得各pod对节点中每种服务资源的资源占用权重；

步骤S2214：根据资源紧缺度权重和资源占用权重，构建第二目标层权重，以获得各pod的目标权重值，并将目标权重值最大的pod确定为待处理的pod。

pod监管模块5还用于确定待处理的pod对节点中每种服务资源的第二资源占用信息的占用预警值；则资源调度模块62根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理时，具体执行如下方法的步骤：若待处理的pod为非资源限制型pod，且其对节点中至少一种服务资源的第二资源占用信息大于pod监管模块5确定的占用预警值，则将该待处理的pod进行副本扩容处理，并将扩容的副本部署至下次服务部署之前确定的目标节点中。

资源调度模块62根据待处理的Pod的种类及其对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理时，还执行如下方法的步骤：若待处理的pod为资源限制型pod，或待处理的pod为非资源限制型pod且其对节点中的每种服务资源的第二资源占用信息均小于占用预警值，则将待处理的pod关闭并生成pod停止信息，并根据pod停止信息将相应的待处理的pod部署至下次服务部署之前节点筛选模块3确定的目标节点中。

可选的，当Pod的种类为资源限制型Pod，第一确定模块1在确定资源被占用信息的预警上限值时，还确定资源被占用信息的第一预警下限值，运行监管模块7在预设的时间间隔内依次遍历各节点中每种服务资源的所述资源被占用信息后，若判断出各节点中没有服务资源的所述资源被占用信息大于预警上限值，则判断各节点中是否有服务资源的资源被占用信息小于第一确定模块1确定的第一预警下限值，若是，则将存在资源被占用信息小于第一预警下限值的节点确定为负载过轻的节点。

资源运算模块6根据Pod的种类、负载信息、SLA违反信息及各pod对节点中每种服务资源的第二资源占用信息，确定是否需对节点上的Pod进行迁移或副本伸缩处理时，资源调度模块62还执行如下方法的步骤：当服务的SLA违反信息超过额定违反阈值，但该服务所在的节点不是负载过重也不是负载过轻的节点，则对该服务的资源限制型pod进行副本扩容处理。

可选的，第一确定模块1确定资源被占用信息的第一预警下限值时，还确定资源被占用信息的第二预警下限值，且第二预警下限值大于第一预警下限值；则资源运算模块6利用其资源调度模块71还执行如下方法的步骤：

若资源限制型Pod所在服务的节点为负载过轻的节点，则对节点上的Pod进行副本缩容处理，并确保缩容处理后服务资源的资源被占用信息小于第二预警下限值。

终上，本发明公开了一种面向Kubernetes的服务管理方法，可用于由相同类型节点(资源类型和数量均相同)组成的集群系统中的服务调度管理，确保在服务部署时将Pod分配到最优节点，并且在服务运行时根据节点负载以及服务质量对服务进行动态调整以使用户获得高质量的服务。主要实现了以下几点：1)将Pod分为两类：一类是资源限制型Pod，另一类是非资源限制型Pod，两类Pod在服务部署以及调度时统一管理；2)结合节点资源、负载情况、服务质量需求等多种因素，采用层次分析法实现服务的优化部署，确保在满足应用需求的同时将Pod分配到最优节点；3)在服务运行过程中，持续监控服务质量以及节点资源使用情况，采用层次分析法选择合适的Pod进行迁移；4)在服务运行过程中，通过对服务副本数量进行伸缩控制，减少SLA违反以及系统资源浪费。本发明公开的方法能够基于服务本身特性和系统资源使用情况，实现对节点物理资源的合理使用，同时提高服务运行过程中的用户满意度。

本发明第三实施例，本发明实施例是在上述两个实施例的基础上，结合附图7-12介绍的一个本发明的应用实例。

本发明实施例提供了一种面向Kubernetes的服务管理方法，主要解决以下两个问题：1)服务优化部署：综合考虑节点资源、负载情况、服务资源需求等多种因素，确保在满足应用需求的同时将Pod分配到最优节点，实现服务的优化部署；2)面向服务质量的服务调度：持续监控服务质量以及节点资源使用情况，合理地对Pod进行迁移，以及对其副本数量进行伸缩控制，缓解节点压力并提升服务质量。

一、为达到以上目的，请参见图11，本发明实施例利用Scheduler-extender将自定义算法(层次分析法)注册为调度插件，配合Kubernetes原有调度器实现提出的服务管理策略，具体采取如下技术方案予以实现：

第一步：服务部署时，采用多准则决策法中的层次分析法选择目标节点，应用Deployment控制器对Pod进行部署。具体包括如下步骤(在本发明实施例中，为确保资源限制型Pod和非资源限制型Pod统一管理，Pod占用资源＝Max(Pod实际资源使用数量，分配给Pod的资源数量))：

将节点的服务资源分为四种：CPU、内存、上行带宽和下行带宽。根据Pod的资源需求情况(即第一实施例中提到的第一资源占用信息)得到资源之间的相对重要性程度，并构建成指标层判断矩阵，该矩阵横纵坐标均为各个服务资源，元素取值为横坐标代表资源相对于纵坐标代表资源的重要性参数。例如，由于某个Pod的CPU资源需求相对于内存重要性略高，则对应元素值可设为2。针对指标层判断矩阵求取最大特征向量，并进行归一化处理，得到每一种服务资源的资源重要性权重的值。

当资源使用信息为节点中每种服务资源未被各pod占用的资源空闲占用率时，构建方案层判断矩阵，每一种资源对应一个矩阵D，如：CPU矩阵横纵坐标为各个节点(Node)，矩阵元素Dij为Nodei的CPU空闲占用率/Nodej的CPU空闲占用率，然后按照上面步骤得到各个Node中CPU空闲占用的权重值。同理构建内存矩阵、上行带宽矩阵、下行带宽矩阵，并求取各个Node对不同资源的权重。

(4)构建最终权重矩阵，求取各节点权重值。Nodei权重值＝CPU资源权重*Nodei空闲CPU资源权重+内存资源权重*Nodei空闲内存资源权重+上行带宽资源权重*Nodei空闲上行带宽资源权重+下行带宽资源权重*Nodei空闲下行带宽资源权重。

(5)选取得分最大的Node作为目标节点，将Pod部署到该节点。在常规的层次分析法中构建比较矩阵时需要进行一致性判断，本发明实施例由于采用真实数据进行对比故不会出现一致性问题。

第二步：系统运行过程中对Pod资源使用情况进行记录。实时监控Pod的资源占用数据(相当于第一实施例中的第二资源占用信息)，利用Kubernetes原有数据库Etcd对Pod资源占用数据进行存储。当后续此类Pod需要调度时，根据该Pod的最新资源使用情况对第一步中的指标层判断矩阵矩阵进行动态更新，例如：记录数据中的最新资源使用情况显示该Pod的CPU占用30％(量化为3)，内存占用20％(量化为2)，则目标层矩阵中CPU对内存的重要性为3/2，对3/2向上取整为2。

第三步：系统运行过程中对服务进行动态调整。当监控发现服务响应时间过长且服务所在节点负载过重，则对该节点上的Pod进行迁移或对该Pod进行副本扩容，以减轻节点负载，提高服务质量。若节点没有出现负载过重，此时需要对响应时间过长的服务副本进行扩容以保障服务质量。具体包括以下步骤：

节点负载监控。采用Pormetheus对节点进行资源监控，Qos控制器每隔一分钟会对各个节点进行依次遍历，如果出现资源占用大于90％，则节点被视为负载过重。

当节点出现负载过重时，同样利用层次分析法，根据节点资源占用情况构建指标层判断矩阵，以及根据各个Pod的资源使用情况构建方案层判断矩阵，每个资源各对应一个矩阵且横纵坐标皆为各个Pod，最终计算得到决策矩阵即各个Pod的权重值。

获取得分最大的Pod，若该Pod占用资源小于40％。Qos控制器会检查集群是否有足够的资源可用，若有空闲资源会kill(关闭)掉该Pod，Deployment控制器收到Pod被kill的信号后会再次通过调度器进行部署。若无可用资源则越过迁移继续监控，直到有可用资源再进行迁移。

(4)得分最大的Pod为非资源限制型且其某一资源占用率大于40％，则对其进行副本扩容处理，即副本数量加一。新副本会通过调度器再次应用层次分析法部署到合适的节点。

(5)当节点没有出现负载过重情况，但仍有服务延迟过大，则由于给该服务对应Pod分配的资源不足，Qos控制器会对该服务的副本进行扩容，增加服务总体的资源占用数量。

第四步：针对资源限制型Pod，当该Pod所在服务占用资源过少时，即：资源使用数量*副本数量(30min平均值)/(单个Pod资源申请数量*(副本数量)-1)<4/5，此时将副本数量减一以减少资源浪费，*表示乘积。

二、对于上述基于层次分析法的自定义调度过程如下：

1.采用层次分析法将问题建模成图8所示的结构，将决策的目标、考虑的因素(决策准则)和决策对象按他们之间的相互关系分成最高层、中间层和最低层：

(1)最高层(目标层)：决策的目的、要解决的问题；

(2)中间层(准则层或指标层)：考虑的因素、决策的准则；

(3)最低层(方案层)：决策时的备选方案；

2.指标比较量化规定：

为方便资源间进行比较，采用如下规定(各类资源利用率——pod需要占用的第一资源占用信息)：0～10％记为1；10％～20％记为2；20％～30％记为3；30％～40％记为4；40％～50％记为5；50％～60％记为6；60％～70％记为7；70％～80％记为8；80％～100％记为9。

3.构建指标层判断矩阵：

1)根据资源重要性构造判断矩阵。

指标层判断矩阵根据通用服务资源需求情况构建，即：CPU较重要于内存，内存较重要于带宽，上行带宽与下行带宽同等重要。

2)算术平均法(和积法)

按列归一化：

方案层判断矩阵构建

若CPU(Nodei)>CPU(Nodej)；

则A1ij＝CPU(Nodei)/CPU(Nodej)，(向上取整)Aji＝1/A1ij；

否则A1ji＝CPU(Nodej)/CPU(Nodei)，(向上取整)Aij＝1/A1ji；

CPU(Nodei)：第i个节点空闲CPU占用率；

CPU:矩阵

若Mem(Nodei)>Mem(Nodej)；

则A2ij＝Mem(Nodei)/Mem(Nodej)，(向上取整)A2ji＝1/A2ij；

否则A2ji＝Mem(Nodej)/Mem(Nodei)，(向上取整)A2ij＝1/A2ji；

Mem(Nodei)：第i个节点空闲内存占用率；

内存矩阵：

若B1(Nodei)>B1(Nodej)

则A3ij＝B1(Nodei)/B1(Nodej)，(向上取整)A3ji＝1/A3ij；

否则A3ji＝B1(Nodej)/B1(Nodei)，(向上取整)A3ij＝1/A3ji；

b1(Nodei)：第i个节点空闲上行带宽占用率；

上行带宽矩阵：

若B2(Nodei)>B2(Nodej)；

则A4ij＝B2(Nodei)/B2(Nodej)，(向上取整)A4ji＝1/A4ij；

否则A4ji＝B2(Nodej)/B2(Nodei)，(向上取整)A4ij＝1/A4ji；

b2(Nodei)：第i个节点空闲下行带宽占用率；

下行带宽矩阵：

5.构建最终权重矩阵

根据最终权重矩阵，Node1获得最大权重值即为所选目标节点，然后将pod部署到目标节点中。

5.Scheduler-extender实现自定义调度：

Schduler extender是Kubernetes外部扩展方式，可以根据需求独立构建调度服务，实现对应的远程调用接口(http),Scheduler在调度的对应阶段会根据用户定义的资源和接口来进行远程调用，对应的service根据自己的资源数据和Scheduler传递过来的中间调度结果来进行决策。

Scheduler-extender只需要实现对应插件的接口，并编写yaml文件来进行注册对应的服务接口，就可以实现Scheduler的扩展，不需要修改任何调度器的代码，即可实现调度插件的插拔。

请参见图11，Scheduler-extender提供了两个接口(Filter和Prioritize)：

Filter接口：Filter主要是用于在预选阶段完成后调用extender进行二次过滤。本发明实施例在此阶段轮询所有Node节点，过滤掉某种资源大于90％的节点，通过的加入到canSchedule，未通的加入到canNotSchedule，返回结果在ExtenderFilterResult。

Prioritize接口：Prioritize主要是用于在优选阶段对各个节点进行打分。本发明实施例在此阶段采用上述层次分析法对节点进行打分并通过http将结果传送给调度器。

Filter接口扩展伪代码如下：

Prioritize接口扩展伪代码如下：

三、基于服务质量的Qos控制器：

1.如图10所示，Kubernetes提供了Client-go库供开发者对其进行二次开发，专利采用官方提供的Client-go库来设计一个Qos控制器来保证服务质量。Qos控制器主要完成以下功能：

1)Qos控制器通过配置的Prometheus(服务监控组件)在固定的时间间隔内不断地获取各个Node的负载情况以及服务的SLA违反情况。

2)当监测到有Node负载过重，则筛选出负载过重的Node，并计算出需要进行处理的Pod(消耗资源较多)，Qos控制器获取该Pod的资源占用情况，根据Pod资源占用的数量来决定迁移或者副本扩容，以减轻该Node的负载。执行迁移的Pod或者新增加的Pod副本会重新通过调度系统部署到合适的节点。

3)当服务的SLA违反数量过多(即相当于实施例一中SLA违反信息超过额定违反阈值，额定违反阈值的具体数值根据服务需求具体设定)，但该服务所在的Node并没有出现负载过重，则考虑副本数量过少导致的资源紧缺，Qos控制器会对该服务副本数量进行扩充。并且，当Pod占用的资源与分配给它的资源比率过低，则副本数量缩减以减少资源的浪费。

2.Qos控制器的设计包含以下内容：

1)Node负载过重判断。

Node资源占用率大于90％(即资源被占用信息大于预警上限值90％)即被定义为负载过重。

11)Node过载处理。

当Node负载过重时，首先根据该Node资源紧缺程度选择出资源占比较大的Pod，然后通过对其进行迁移或者副本扩容操作来缓解Node的压力。Pod的选择同样采用层次分析法。将指标层矩阵横纵坐标设置为Node中各类资源，矩阵中各元素为对应Node之间的该资源占用率之比；方案层根据各类资源构建不同的判断矩阵，每类资源的矩阵横纵坐标为各个Pod，各矩阵元素值为对应Pod之间的该资源的使用率之比。最后计算出目标矩阵，根据加权和选出需要进行处理的Pod。

12)筛选待处理的pod时，采用层次分析法将问题建模成图9所示的结构。

将决策的目标、考虑的因素(决策准则)和决策对象按他们之间的相互关系分成最高层、中间层和最低层：

(1)最高层(目标层)：决策的目的、要解决的问题；

(2)中间层(准则层或指标层)：考虑的因素、决策的准则；

(3)最低层(方案层)：决策时的备选方案；

a.指标比较量化规定：

为方便资源间进行比较，采用如下规定(各类资源利用率——资源被占用信息具体为资源被占用率时的数据)：0～10％记为1；10％～20％记为2；20％～30％记为3；30％～40％记为4；40％～50％记为5；50％～60％记为6；60％～70％记为7；70％～80％记为8；80％～100％记为9。

b.构建指标层判断矩阵：

根据资源紧缺程度构造判断矩阵。

根据节点资源被占用情况构建指标层判断矩阵，如：Node1出现负载过重，此时各资源被占用率为：CPU：90％(量化为9)，内存：80％(量化为8)，上行带宽：40％(量化为5)，下行带宽：30％(量化为3)。Z12＝90/80(向上取整)＝2则Z21＝1/2；Z13＝90/40(向上取整)＝3则Z31＝1/3，矩阵其他元素同理。

c.算术平均法(和积法)

按列归一化：

方案层判断矩阵构建

若CPU(Podi)>CPU(Podj)；

则A1ij＝CPU(Podi)/CPU(Podj)，(向上取整)Aji＝1/A1ij；

否则A1ji＝CPU(Podj)/CPU(Podi)，(向上取整)Aij＝1/A1ji；

CPU(Podi)：第i个Pod的CPU占用率；

CPU:矩阵

若Mem(Podi)>Mem(Podj)，Mem表示内存资源；

则A2ij＝Mem(Podi)/Mem(Podj)，(向上取整)A2ji＝1/A2ij；

否则A2ji＝Mem(Podj)/Mem(Podi)，(向上取整)A2ij＝1/A2ji；

Mem(Podi)：第i个Pod的内存占用率；

内存矩阵：

若B1(Podi)>B1(Podj)，

则A3ij＝B1(Podi)/B1(Podj)(向上取整)A3ji＝1/A3ij；

否则A3ji＝B1(Podj)/B1(Podi)(向上取整)A3ij＝1/A3ji；

B1(Podi)：第i个Pod的上行带宽占用率；

上行带宽矩阵：

若B2(Podi)>B2(Podj)；

则A4ij＝B2(Podi)/B2(Podj)(向上取整)A4ji＝1/A4ij；

否则A4ji＝B2(Podj)/B2(Podi)(向上取整)A4ij＝1/A4ji；

B2(Podi)：第i个Pod的下行带宽占用率；

下行带宽矩阵：

d.构建最终权重矩阵

根据最终权重矩阵，Pod1获得最大权重值即为所选目标节点。

13)副本扩容

当得到需要处理的Pod之后，首先要判断其资源占用率(即第二资源占用信息)，若该Pod为非资源限制型Pod且某一种服务资源的资源占用率大于40％(占用预警值)，将它迁移至另一节点Node后资源的使用同样会过度占用资源，因此对于这种Pod最好的方法是进行扩容处理，系统通过调用client-go接口来修改Pod所在Deployment的replicas字段，使其副本数量减一。

14)Pod迁移

当待处理Pod为资源限制型Pod，或Pod为非资源限制型Pod且各资源占用率均小于40％(占用预警值)，系统通过client-go接口关闭该Pod，然后Deployment收到Pod停止信息后会重新部署该Pod，Pod会通过自定义调度算法再次部署到资源竞争相对较小的节点Node中。

5.资源限制型Pod资源紧张导致服务质量变低的处理

针对资源限制型Pod由于初始定义时对此类Pod限制了资源使用数量，当用户请求量暴增时可能由于分配的资源不够导致服务质量变低，此时系统会对该Pod所在的服务进行扩容处理，调用client-go接口中Deployment的Replicas方法使副本数量加一，为该服务分配更多的资源来提高服务质量。

6.资源限制型Pod资源回收处理

非限制Pod是跟据实际情况来使用资源，当用户请求量低时资源占用就会少，在此阶段可不用考虑。对于资源限制型Pod可出现这种情况：假设服务1有四个Pod副本，每个副本的内存分配为400m，但是四个副本在30分钟内实际使用的平均内存皆为200m，此时会有大量内存资源空闲，但是其它服务又不能使用这些资源从而导致资源的浪费，此时可考虑对服务的副本进行缩容，若缩容后的资源使用：200*4/(400*(4-1))<80％(第二预警下限值),即可对副本数量进行减一。由于每个副本的本身的一些控制会占用一些资源，因此计算出来的资源使用只会比实际更低。

Qos控制器伪代码如下：

本发明提出的面向Kubernetes的服务管理方法具有以下优点及效果：

利用层次分析法优化服务部署，充分考虑节点资源的使用情况和Pod对于各种资源的需求情况，根据资源的重要性来确定各类资源权重并最终筛选出目标节点。资源权重矩阵在系统运行过程中可以动态更新，更加合理地对Pod进行部署。

在服务运行过程中最大限度的保障服务的质量，从Pod迁移和Pod副本扩容两方面缓解节点负载过重，提升服务质量。同时，若当前节点负载过低则通过适当减少服务的副本数量以减少资源浪费。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指控制用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。