CN114826908A

CN114826908A - kubernetes集群服务保障方法、组件、系统

Info

Publication number: CN114826908A
Application number: CN202210498760.4A
Authority: CN
Inventors: 唐祁
Original assignee: Xinhua Zhiyun Technology Co ltd
Current assignee: Xinhua Zhiyun Technology Co ltd
Priority date: 2022-05-09
Filing date: 2022-05-09
Publication date: 2022-07-29
Anticipated expiration: 2042-05-09
Also published as: CN114826908B

Abstract

本发明公开一种kubernetes集群服务保障方法、组件、系统，其中保障方法包括服务修复方法和服务调度方法；服务修复方法用于当节点的资源使用总量达到预设的使用量阈值时，基于节点内各服务的资源使用量和重要程度选举待修复服务，在保证节点状态稳定的同时，还能保证服务的运行呈现稳态。服务调度方法用于调度作为待调度服务的新增服务或待修复服务，包括以下步骤：当所述待调度服务是重要服务时，将不存在重要服务的候选节点作为预选节点；计算所述待调度服务和各预选节点的匹配度，基于所述匹配度从预选节点中提取优选节点，并将所述待调度服务调度至相应的优选节点上。本发明能够保障重要服务独立稳定运行。

Description

kubernetes集群服务保障方法、组件、系统

技术领域

本发明涉及信息处理领域，尤其涉及一种kubernetes集群服务保障技术。

背景技术

kubernetes简称k8s，是目前容器化微服务的重要工具，通过kubernetes可以将原本庞大的服务细分成以作用为颗粒的微服务，可以很好地降低开发以及运维成本。

现今Kubernetes提供的服务质量等级(QoS，Quality of Service)以实现集群内微服务的优先级排序，但是Kubernetes提供的Qos值仅通过服务资源最低保障值与最高保障值获得，因此基于Kubernetes提供的QoS值并不能准确表征服务的重要程度，尤其是服务在业务体系中的重要程度。现今在当Kubernetes集群中节点出现资源使用率过高的情况下，基于服务质量等级对节点的微服务进行驱逐，此方案无法保证Kubernetes集群中重要的服务稳定运行。

发明内容

本发明针对现有技术仅基于服务质量等级对节点的微服务进行驱逐的方案，无法保证Kubernetes集群中重要的服务稳定运行缺点，提供了一种kubernetes集群服务保障技术。

为了解决上述技术问题，本发明通过下述技术方案得以解决：

一种kubernetes集群服务保障方法，包括以下步骤：

基于目标节点的资源使用总量判断是否对所述目标节点内的服务进行修复；

当判定对所述目标节点内的服务进行修复时：

获取目标节点中各服务的重要等级和资源使用量，所述重要等级为基于重要性评分对目标节点中各服务的分级，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分；

基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务，令修复后的目标节点的资源使用总量小于预设的使用量阈值。

作为一种可实施方式，所述重要等级的获取方式为：

获取目标节点中各服务的重要性评分；

令目标节点中各服务基于重要性评分进行排序，并根据排序结果对各服务进行定级，获得相应的重要等级。

作为一种可实施方式，基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务的具体步骤为：

按照重要程度从高到低的顺序，重要等级包括第一级和第二级；

基于目标节点的资源使用总量，以及服务的资源使用量，选择重要等级为第二级的一个或多个服务作为待修复服务。

本申请还提出一种kubernetes集群服务保障方法，包括以下步骤：

获取待调度服务，所述待调度服务为新增服务或待修复服务；

获取与所述待调度服务相对应的候选节点，并基于重要性评分判断所述待调度服务是否为重要服务，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分；

当所述待调度服务是重要服务时，判断各候选节点中是否存在重要服务，将不存在重要服务的候选节点作为预选节点；当所述待调度服务不是重要服务时，将所有候选节点作为预选节点；

计算所述待调度服务和各预选节点的匹配度，基于所述匹配度从预选节点中提取优选节点，并将所述待调度服务调度至相应的优选节点上。

作为一种可实施方式：

基于重要性评分，将重要程度属于集群前N的服务作为重要服务，其中N为预设的服务个数或服务占比。

作为一种可实施方式：

副本分布数据包括对应服务的生产环境副本数、测试环境副本数和预发环境副本数；

资源使用数据包括CPU最小使用量和CPU最大使用量；

被依赖数据包括被依赖服务的重要性评分，所述被依赖服务指依赖对应服务的服务。

作为一种可实施方式，匹配度的计算方法包括以下步骤：

获取待调度服务的重要性评分；

获取预选节点上各服务的重要性评分，获得所述预选节点相对应的重要性总分；

计算所述重要性评分和所述重要性总分的差值，将所得差值的绝对值作为所述待调度服务和所述预选节点的匹配度。

本申请还提出一种kubernetes集群服务保障组件，包括：

修复检测模块，用于基于目标节点的资源使用总量判断是否对所述目标节点内的服务进行修复；

服务选举模块，用于当判定对所述目标节点内的服务进行修复时，从所述目标节点中选择一个或多个服务作为待修复服务；

所述服务选举模块包括：

数据获取单元，用于获取目标节点中各服务的重要等级和资源使用量，所述重要等级为基于重要性评分对目标节点中各服务的分级，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分；

选举单元，用于基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务，令修复后的目标节点的资源使用总量小于预设的使用量阈值。

本申请还提出一种kubernetes集群服务保障组件，包括：

获取模块，用于获取待调度服务，所述待调度服务为新增服务或待修复服务；

预处理模块，用于获取与所述待调度服务相对应的候选节点，并基于重要性评分判断所述待调度服务是否为重要服务，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分；

节点筛选模块，用于当所述待调度服务是重要服务时，判断各候选节点中是否存在重要服务，将不存在重要服务的候选节点作为预选节点；当所述待调度服务不是重要服务时，将所有候选节点作为预选节点；

节点优选模块，用于计算所述待调度服务和各候选节点的匹配度，基于所述匹配度从预选节点中提取优选节点，并将所述待调度服务调度至相应的优选节点上。

进一步地：

预处理模块，还用于计算候选节点上各服务的重要性评分，获得所述候选节点相对应的重要性总分。

节点优选模块，用于获取待调度服务的重要性评分，还用于获得所述预选节点相对应的重要性总分，并计算所述重要性评分和所述重要性总分的差值，将所得差值的绝对值作为所述待调度服务和所述预选节点的匹配度。

本申请还提出一种kubernetes集群服务保障系统，包括：

评分组件，用于计算集群内各服务的重要性评分，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分；

修复组件，包括修复检测模块和服务选举模块：

调度组件，包括：

本发明由于采用了以上技术方案，具有显著的技术效果：

本发明基于服务的副本数维度、资源使用维度和依赖维度对Kubernetes集群内的服务进行评分，以获得相应的重要性评分，基于重要性评分对于节点中各服务进行定级，获得相应的重要等级，基于重要等级和资源使用量选举待修复服务，保证节点状态稳定的同时，还能保证服务的运行呈现一个稳态。

本发明通过重要性评分确定集群中的重要服务，以在调度过程中避免重要服务在同一节点上运行，从而避免了重要服务之间抢占资源情况的发生，进而保障重要服务都可以独立稳定运行。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明服务修复方法的流程示意图；

图2是本发明服务调度方法的流程示意图；

图3是本发明服务修复组件的结构示意图；

图4是图3中修复代理110的模块连接示意图；

图5是本发明服务调度组件的模块连接示意图。

具体实施方式

下面结合实施例对本发明做进一步的详细说明，以下实施例是对本发明的解释而本发明并不局限于以下实施例。

实施例1、一种kubernetes集群服务保障方法，包括服务修复方法，所述服务修复方法用于当节点的资源使用总量达到预设的使用量阈值时，基于节点内各服务的资源使用量和重要程度选举待修复服务，以驱逐待修复服务，即能够保证集群节点的状态稳定，又能够保证集群内重要的服务运行稳定。

包括以下步骤：

S110、基于目标节点的资源使用总量判断是否对所述目标节点内的服务进行修复；

注，本实施例所述目标节点内的服务指微服务在对应节点中的pod。

S120、当判定对所述目标节点内的服务进行修复时，从所述目标节点中选择一个或多个服务作为待修复服务，令修复后的目标节点的资源使用总量小于预设的使用量阈值令修复后的目标节点的资源使用总量小于预设的使用量阈值；

具体步骤为：

S121、获取目标节点中各服务的重要等级和资源使用量；

所述重要等级为基于重要性评分对目标节点中各服务的分级，所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分，用于指示服务的重要程度；

S122、基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务，令修复后的目标节点的资源使用总量小于预设的使用量阈值。

即，当前目标节点的资源使用总量减去各待修复服务资源使用量，即可计算获得修复后的目标节点的资源使用总量。

由于存在服务不重要但是资源使用率很高的情况，如仅基于各服务的资源使用量选举待修复服务，能够优化节点资源使用率，但不一定能够保障重要服务的正常运行；

Kubernetes提供服务质量等级QoS是基于服务CPU/内存的limits与requests值的所确定的，服务质量等级QoS无法作为准确评判服务是否重要的标准，如仅基于资源使用量和服务质量等级QoS选举待修复服务，亦无法保障重要服务的正常运行；

本实施例中基于服务的副本数维度、资源使用维度和依赖维度对Kubernetes集群内的服务进行评分，以获得相应的重要性评分，基于重要性评分对于节点中各服务进行定级，获得相应的重要等级，基于重要等级和资源使用量选举待修复服务，保证节点状态稳定的同时，还能保证服务的运行呈现一个稳态。

步骤S121中所述的重要等级的获取方式为：

获取目标节点中各服务的重要性评分；

本实施例中，重要性评分越高表示服务的重要程度越高，故令目标节点中各服务按照重要性评分从高到低的顺序进行排序，之后基于预设的定级规则对各服务进行定级，本领域技术人员可根据实际情况自行设定定级规则；

本实施例中，将10％的服务定级为第一级，剩余服务定级为第二级，第一级的重要程度高于第二级，第一级的服务不可作为待修复服务，第二级的服务可作为待修复服务；

本领域技术人员还可对第二级的服务做进一步划分，例如，将10％的服务定级为第一级，将30％的服务定级为次要修复级别，将剩余服务定级为主要修复级别，其中次要修复级别和主要修复级别的服务共同构成第二级，且按照重要程度从高到低的顺序，重要等级依次为第一级、次要修复级别和主要修复级别。

步骤S122中基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务的具体步骤为：

本领域技术人员可根据实际需要自行设定选举规则；

当重要等级仅包括第一级和第二级时，选举规则例如可设置为：

按照重要性评分从低到高的顺序，从重要等级为第二级的服务中，选择一个或多个服务作为待修复服务，直至令修复后的目标节点的资源使用总量小于预设的使用量阈值。

当重要等级包括第一级、次要修复级别和主要修复级别时，可设置各等级的选举条件，例如第一级为不被选举，次要修复级别为人工确定是否能被选举，主要修复级别为能被选举，参照图1，按照以下顺序进行待修复服务的选举：

①、获取目标节点中的资源使用量最高的服务的重要等级；

②、当步骤①中所得重要等级为第一级时，执行第⑥步；

③、当步骤①中所得重要等级为次要修复级别，询问人工是否可直接对该服务进行修复，如果可直接进行修复，则将该服务作为待修复服务，执行第⑤步，否则，执行步骤⑥；

④、当步骤①中所得重要等级为主要修复级别，则将该服务作为待修复服务，执行第⑤步；

⑤、判断驱逐待修复服务后，目标节点的资源使用总量是否小于预设的使用量阈值；

即，目标节点的资源使用总量与各待修复服务的资源使用总量的差，判断所得差是否小于预设的使用量阈值；

如果小于预设的使用量阈值，结束选举，否则进行步骤⑥；

⑥、从剩余的重要等级为主要修复级别或次要修复级别的服务中(不含待修复服务)，选择重要性评分最低的服务作为待修复服务后，进行步骤⑤。

以下通过一个具体的案例进行详细介绍：若资源使用量最高的服务属于第一级的服务，如下表所示。

表1

服务名	重要性评分	定级	资源使用量
				Task1	100	第一级	50％
Task4	87	次要修复级别	10％
				Task3	43	次要修复级别	2％
Task2	3	主要修复级别	3％

选择主要修复级别别的服务Task2作为待修复服务，此时目标节点的资源使用总量与各待修复服务的资源使用总量的差；

如资源使用总量为99％，所得差为(99-3)％＝96％，仍然大于使用量阈值95％，此时按照重要性评分选择次要修复级别别的服务Task3作为待修复服务，所得差为(96-2)％＝94％，该值小于使用量阈值95％，完成选举，即，将Task2和Task3为待修复服务进行修复。

若资源使用量最高的服务属于次要修复级别别的服务，如下表所示。

表2

服务名	重要性评分	定级	资源使用量
				Task1	100	第一级	20％
Task4	87	次要修复级别	30％
				Task3	43	次要修复级别	40％
Task2	3	主要修复级别	3％

首先通知相关人员Task3是否可以被用于修复任务；

如果可以，将Task3作为待修复服务；

如果不可以，基于重要性评分选择主要修复级别别的服务Task2作为待修复服务，并判断目标节点的资源使用总量与各待修复服务的资源使用总量的差是否小于使用量阈值，本案例中差为(99-3)％＝96％，该值仍然大于阈值95％，故继续选择次要修复级别别的服务Task3作为待修复服务，所得差为(96-40)％＝54％，该值小于使用量阈值95％，完成选举，即，将Task2和Task3为待修复服务进行修复。

若资源使用量最高的服务属于主要修复级别别的应用，如下表所示：

表3

直接选取Task2为修复服务。

综上，本实施例通过重要等级和资源使用量，针对不同重要等级的服务进行对应的修复，有效避免重要程度低的服务抢占重要程度高的服务的资源，避免了节点上服务因资源抢占而卡死的问题，保证了服务运行的稳定性。

实施例2、一种kubernetes集群服务保障方法，包括服务调度方法，用于进行服务调度，参照图2，包括以下步骤：

S210、获取待调度服务；

所述待调度服务为新增服务或待修复服务；

本实施例中，待修复服务为基于实施例1所公开的方法选举获得的待修复服务；

S220、预处理：

S221、获取与所述待调度服务相对应的候选节点；

基于现有已公开的节点预选方法获取与所述待调度服务相对应的候选节点，本实施例中使用kubernetes scheduler默认的节点预选策略进行预选。

S222、基于重要性评分判断所述待调度服务是否为重要服务；

所述重要性评分为基于服务的副本分布数据、资源使用数据和被依赖数据所生成的评分，用于指示服务的重要程度；

S230、对所得的候选节点进行筛选，获得预选节点，具体步骤为：

S231、当所述待调度服务是重要服务时，筛选步骤如下：

判断各候选节点中是否存在重要服务，将不存在重要服务的候选节点作为预选节点；

S232、当所述待调度服务不是重要服务时，将所有候选节点作为预选节点；

S240、计算所述待调度服务和各预选节点的匹配度，基于所述匹配度从预选节点中提取优选节点，并将所述待调度服务调度至相应的优选节点上。

本实施例通过重要服务的判断，避免重要服务在同一节点上运行，从而避免了重要服务之间抢占资源情况的发生，进而保障重要服务都可以独立稳定运行。

步骤S240中计算所述待调度服务和各预选节点的匹配度的具体步骤为：

获取待调度服务的重要性评分；

本实施例将匹配度最高的预选节点作为优选节点，当存在多个优选节点时，可将待调度服务调度至任意一个优先节点上。

本实施例对匹配度的设计，使得重要性评分高的服务调度到重要性总分低的节点，重要性评分低的服务调度到重要性总分高的节点，通过本实施例对匹配度的运用，将匹配度高的候选节点选择为优选节点，进而进行服务调度，使整个集群内所有的节点分值趋于近似，从而让集群整体实现稳态。

进一步地：

本领域技术人员可根据实际需要自行设定重要服务的判断规则，本实施例中将重要程度属于集群前25％的服务作为重要服务。

例：

现有节点node，在节点上运行的服务以及他们所对应的分值如下表1所示：

表4

服务名	重要性评分
		Task1	100
Task2	3
		Task3	43
Task4	87

现有待调度服务Task5，其分值为98分。当kubernetes scheduler对节点node进行节点预选操作时，则进行以下步骤：

基于重要性评分判断Task5是否为重要服务，本案例中Task5重要性评分为98分，属于重要服务；

对节点node上所有服务进行分值查询，以判断节点node是否存在重要服务；本案例中Task1的重要性评分为100，属于重要服务，因此不将节点node作为预选节点。

进一步地：

资源使用数据包括CPU最小使用量和CPU最大使用量；

本实施例中重要性评分的计算步骤为：

S310、获取待评分服务；

所述待评分服务为kubernetes集群内需要进行重要性评估的服务；

例如，将新部署的微服务作为待评分服务，对其进行重要性的评估。

本实施例中将新部署的、非不重要的服务作为待评分服务，具体获取步骤如下：

获取新增服务，检测所述新增服务的重要性标识；

当基于所得检测结果判定所述新增服务为不重要服务时，将预设的初始分作为所述新增服务的重要性评分，否则，将所述新增服务作为待评分服务。

本领域技术人员可根据实际需要自行设定重要标识；

本实施例中，将“test”作为重要性标识，其标识对应服务为不重要服务；

在实际应用中，将集群中新部署的服务作为新增服务，查询新增服务的对应的名称中是否包含“test”，如包含，判定所述新增服务为不重要服务，直接将预设的初始分作为重要性评分输出，否则判定所述新增服务为待评分服务，此时将新增服务作为待评分服务对其重要性进行评估。

本实施例通过对重要性标识的判断，预先筛选出不重要的服务，无需对不重要的服务进行评估，减少计算量以及对计算资源的占用。

S320、获取所述待评分服务的第一基础分、第二基础分和依赖分；

S321、第一基础分：

本实施例中，基于待评分服务的副本数量生成第一基础分；

副本数量与对应服务的重要性成正比关系，即，服务在集群中的副本数越高，该服务重要的可能性就越大；

具体获取方法如下：

①、获取所述待评分服务在对应kubernetes集群内的副本分布数据；

所述副本分布数据包括测试环境副本数、预发环境副本数和生产环境副本数

服务存在于集群的形式有三种，即测试环境、预发环境和生产环境；

查询待评分服务在各环境下的副本数量，即可获得相应的副本数；

②、基于所述副本分布数据生成所述第一基础分；

本领域技术人员可根据实际需要，自行设置计算规则以基于测试环境副本数、预发环境副本数和生产环境副本数计算第一基础分；

本实施例中基于副本分布数据生成第一基础分的具体步骤为：

基于测试环境副本数计算获得测试环境分：

测试环境副本数相对于其他环境的副本数，与待评分服务的重要性关联度最低，故可减少测试环境副本数对第一基础分的影响程度；

本实施例中测试环境分r_test的计算公式如下：

r_test＝min{Replicas_test-a₁，b₁}；

其中，Replicas_test表示测试副本数，a₁为测试环境削减参数，b₁为测试环境基准参数，本领域技术人员可根据实际需要自行配置a₁和b₁的取值。

基于预发环境副本数计算获得预发环境分：

例如可将预发环境副本数作为预发环境分，或基于实际需要自行设定预发环境分的计算规则，本实施例中预发环境分r_pre的计算公式如下：

r_pre＝Replicas_pre-a₂；

其中，Replicas_pre表示预发副本数，a₂为预发环境削减参数，本领域技术人员可根据实际需要自行配置a₂的取值。

基于生产环境副本数计算获得生产环境分：

生产环境副本数相对于其他环境的副本数，与待评分服务的重要性关联度最高，且由于生产环境需要对服务进行高可用的保障，故需要保证生产环境分不低于预设的最低分；

本实施例中预发环境分r_prod的计算公式如下：

r_prod＝max{Replicas_prod-a₃，b₃}；

其中，Replicas_prod表示生产副本数，a₃为生产环境削减参数，b₂为生产环境基准参数，本领域技术人员可根据实际需要自行配置a₃和b₃的取值。

基于测试环境分、预发环境分和生产环境分生成第一基础分：

本实施例中，将测试环境分、预发环境分和生产环境分的和作为第一基础分；

本领域技术人员还可根据实际需要进行加权求和以获得相应的第一基础分，本说明书不对其进行详细限定。

S322、第二基础分：

本实施例中，基于待评分服务的CPU资源占用情况生成第二基础分；

具体获取方法如下：

①、获取所述待评分服务的资源使用数据；

所述资源使用数据包括CPU最小使用量和CPU最大使用量；

当CPU最小使用量和CPU最大使用量较为接近时，说明该服务的资源必须要一次满足，由此可证明该待评分服务的重要性更高；

相反，当CPU最小使用量和CPU最大使用量差距较大时，说明该服务的资源无需一次满足，因此推断出该服务重要性更低。

②、基于所述资源使用数据生成所述第二基础分。

即，基于CPU最小使用量占CPU最大使用量的比率，生成第二基础分，该比率越大，待评分服务越重要，第二基础分越高。

S323、依赖分：

本实施例中，基于待评分服务的被依赖情况生成依赖分；当某个服务出现异常时，依赖该服务的其他服务都无法保障正常运行，故对于被依赖服务数据越多、被依赖服务重要性评分越高，待评分服务也越重要。

具体获取方法如下：

①、获取依赖所述待评分服务的服务，获得相应的被依赖服务；

例如，服务A依赖服务B，即，服务B被服务A所依赖，服务A为服务B的被依赖服务；

②、获取并汇总各被依赖服务的重要性评分，生成待评分服务的依赖分。

例如，服务B的被依赖服务为服务A和服务C，此时查询服务A和服务C的重要性评分后求和，将所得和作为服务B的依赖分。

S324、调整分(可为空)；

所述调整分为工作人员根据实际需要配置的评分数据；

工作人员可预先为对需要重点保障的服务配置调整分，以提高其重要性评分；

需要重点保障的应用服务为工作人员人工评判的，或，按照预设的规则查询待评分服务的性能指标，例如QPS(QueryPerSecond)，并给予性能指标判断所述服务是否是重要服务，当评判其是重要服务后，将其推送至相应工作人员，由对应工作人员进行调整分的配置。

S330、基于所述第一基础分、所述第二基础分和所述依赖分生成所述待评分服务的重要性评分。

注，可在生成所述待评分服务的重要性评分前获取调整分，以基于第一基础分、第二基础分、依赖分和调整分共同生成待评分服务的重要性评分，还可在待评分服务具有重要性评分后，基于调整分对所述重要性评分进行更新

现今支持公司层面对于业务需求进行优先级排序，即，人工对业务的重要程度进行配置，按照业务的重要程度进行优先级划分，优先处理重要程度高的业务，但一项业务的实现，往往需要若干个微服务配合工作得以实现，且不同优先级的业务可能会调用相同的微服务，故业务和微服务的重要度评分不能简单等同；

目前Kubernetes集群中缺少对微服务的重要性评分，在资源分配和服务调度过程中，仅在资源维度考虑服务所需的资源以及节点剩余的资源，无法有效保障重要服务的运行稳定性；

本实施例所提出的评估方案，通过待评分服务的副本分布数据、资源使用数据和被依赖数据，于副本数维度、资源使用维度和依赖维度对待评分服务的重要性进行评分，以便于后续资源分配和服务调度工作中基于重要性评分保障重要的服务的稳定运行。

S340、更新触发步骤：

查询所述待评分服务所依赖的服务，获得相应的依赖服务；

将所述依赖服务标记为待更新服务。

S350、更新待更新服务的重要性评分：

检测所述待更新服务的重要性标识；

当基于重要性标识判定所述待更新服务为不重要服务时，结束当前更新任务，即，不对所述待更新服务的重要性评分进行更新；

当基于重要性标识判定所述待更新服务非不重要服务时，进行评分更新步骤，具体为：

获取所述待更新服务的被依赖服务；

获取各被依赖服务的重要性评分；

基于各被依赖服务的重要性评分更新所述待更新服务的依赖分和重要性评分。

即，某一服务的重要性评分发生变化(新生成重要性评分或重要性评分更新后)后，对该服务所依赖的其他服务的重要性评分进行更新；

服务的副本分布数据和资源使用数据在集群初始化后往往不在变化，且相比依赖关系，副本分布数据和资源使用数据对服务重要性对的影响较小，故仅在实际使用过程中对各服务的依赖分进行自动更新，即可实现对各服务的重要性评分进行动态更新，为后续的服务调度和资源分配提供数据基础。

实施例3、一种kubernetes集群服务保障组件，作为服务修复组件100，用于对节点的资源使用总量进行监测，还用于当节点的资源使用总量超过预设的使用量阈值使，基于节点内各服务的资源使用量和重要程度选举待修复服务，参照图3，包括：控制器120和若干修复代理110，所述修复代理110与节点一一对应；

参照图4，所述修复代理110包括：

修复检测模块111，用于基于目标节点的资源使用总量判断是否对所述目标节点内的服务进行修复，该修复代理所在的节点为目标节点；

服务选举模块112，用于当判定对所述目标节点内的服务进行修复时，从所述目标节点中选择一个或多个服务作为待修复服务；

所述服务选举模块112包括：

数据获取单元，用于获取目标节点中各服务的重要等级和资源使用量，所述重要等级为基于重要性评分对目标节点中各服务的分级；

所述控制器120分别与各修复代理110以及外部的服务调度组件200信号相连，用于接收修复代理上报的待修复服务，并将所述待修复服务发送至服务调度组件200进行调度，以实现修复。

实施例4、一种kubernetes集群服务保障组件，作为服务调度组件200，用于进行服务调度，参照图5，包括：

获取模块210，用于获取待调度服务，所述待调度服务为新增服务或待修复服务，本实施例中待修复服务为基于实施例1所公开的方案所选举的待修复服务；

预处理模块220，用于获取与所述待调度服务相对应的候选节点，并基于重要性评分判断所述待调度服务是否为重要服务，所述重要性评分用于指示服务的重要程度；

节点筛选模块230，用于当所述待调度服务是重要服务时，判断各候选节点中是否存在重要服务，将不存在重要服务的候选节点作为预选节点；当所述待调度服务不是重要服务时，将所有候选节点作为预选节点；

节点优选模块240，用于计算所述待调度服务和各候选节点的匹配度，基于所述匹配度从预选节点中提取优选节点，并将所述待调度服务调度至相应的优选节点上。

进一步地：

预处理模块220，还用于计算候选节点上各服务的重要性评分，获得所述候选节点相对应的重要性总分。

节点优选模块240，用于获取待调度服务的重要性评分，还用于获得所述预选节点相对应的重要性总分，并计算所述重要性评分和所述重要性总分的差值，将所得差值的绝对值作为所述待调度服务和所述预选节点的匹配度。

实施例5、一种kubernetes集群服务保障系统，包括：

评分组件，用于计算集群内各服务的重要性评分，所述重要性评分用于指示服务的重要程度，还用于基于重要性评分标记服务是否是重要服务；

修复组件，采用实施例3所述的kubernetes集群服务保障组件；

调度组件，采用实施例4所述的kubernetes集群服务保障组件。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

需要说明的是：

说明书中提到的“一个实施例”或“实施例”意指结合实施例描述的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，说明书通篇各个地方出现的短语“一个实施例”或“实施例”并不一定均指同一个实施例。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

此外，需要说明的是，本说明书中所描述的具体实施例，其零、部件的形状、所取名称等可以不同。凡依本发明专利构思所述的构造、特征及原理所做的等效或简单变化，均包括于本发明专利的保护范围内。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，只要不偏离本发明的结构或者超越本权利要求书所定义的范围，均应属于本发明的保护范围。

Claims

1.一种kubernetes集群服务保障方法，其特征在于，包括以下步骤：

当判定对所述目标节点内的服务进行修复时：

2.根据权利要求1所述的kubernetes集群服务保障方法，其特征在于，所述重要等级的获取方式为：

获取目标节点中各服务的重要性评分；

3.根据权利要求1或2所述的kubernetes集群服务保障方法，其特征在于，基于所述重要等级和所述资源使用量，从所述目标节点中选择一个或多个服务作为待修复服务的具体步骤为：

4.一种kubernetes集群服务保障方法，其特征在于，包括以下步骤：

5.根据权利要求4所述的一种kubernetes集群服务保障方法，其特征在于：

6.根据权利要求4或5所述的一种kubernetes集群服务保障方法，其特征在于：

资源使用数据包括CPU最小使用量和CPU最大使用量；

7.根据权利要求4或5所述的一种kubernetes集群服务保障方法，其特征在于，匹配度的计算方法包括以下步骤：

获取待调度服务的重要性评分；

8.一种kubernetes集群服务保障组件，其特征在于，包括：

所述服务选举模块包括：

9.一种kubernetes集群服务保障组件，其特征在于，包括：

10.一种kubernetes集群服务保障系统，其特征在于，包括：

修复组件，采用权利要求8所述的kubernetes集群服务保障组件；

调度组件，采用权利要求9所述的kubernetes集群服务保障组件。