一种集节点故障处理方法、系统及介质与流程

1.本发明涉及计算机技术领域，尤其涉及一种集节点故障处理方法、系统及存储介质。

背景技术：

2.kubernetes(简称k8s)是google开源的用于管理容器化的系统，一般可以将web应用迁移到kubernetes集上。kubernetes集部署了多个节点和节点组件等。
3.现有技术中，对于kubernetes集的故障检测及处理方案更多的是依赖监控组件的监控，若监控到某一集节点出现故障，通过手动的方式进行恢复，在恢复期间，主节点中的调度程序会将容器组件调度到当前发生故障的节点，从而影响业务的运行。
4.因此，如何在集节点出现故障时，仍然可以保证业务正常运行成为亟待解决的问题，

技术实现要素：

5.本发明提供了一种集节点故障处理方法、系统及存储介质，以解决现有技术中，若某一集节点出现故障，而kubernetes仍然将工作负载调度到当前节点而影响业务的问题，实现快速的检测到节点的故障并隔离故障节点，从而保证业务正常的运行。
6.根据本发明的一方面，提供了一种集节点故障处理方法，包括：
7.通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息；
8.通过故障决策组件对所述故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签；
9.通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的apiserver组件，所述故障处理消息用于指示apiserver组件执行故障处理操作。
10.根据本发明的另一方面，提供了一种集节点故障处理系统，包括：
11.普通节点，用于通过故障检测组件获取本节点的组件故障或硬件故障，根据检测结果生成故障节点信息，发送故障节点信息给执行上述的集节点的故障处理方法的健康节点；
12.所述健康节点，用于上述的集节点的故障处理方法的健康节点；
13.主节点，用于通过apiserver组件获取所述健康节点发送的故障处理消息，根据所述故障处理消息确定具有污点标签的故障节点，通过scheduler组件暂停将新的容器组pod调度到具有污点标签的故障节点，或者，在暂停将新的容器组pod调度到具有污点标签的故障节点的基础上，对具有污点标签的故障节点上的已有容器组pod进行驱逐。
14.根据本发明的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使处理器执行时实现本发明任一实施例所述的一种集节点故障处理方法。
15.本发明实施例的技术方案，可以快速的检测到集中发生的故障节点并通过设置
污点标签隔离该故障节点，从而保证业务正常的运行。
16.应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。
附图说明
17.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1a是现有技术提供的kubernetes集的各个节点结构示意图；
19.图1b是根据本发明实施例一提供的一种集节点故障处理方法的流程图；
20.图2是根据本发明实施例二提供的又一种集节点故障处理方法的流程图；
21.图3是根据本发明实施例三提供的另一种集节点故障处理方法的流程图；
22.图4是根据本发明实施例四提供的一种集节点故障处理系统的结构示意图。
具体实施方式
23.为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
24.需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
25.目前，对于kubernetes集，图1a展示了kubernetes集的各个节点，如图1a所示：其主节点可以是master，用于负责整个集的管理和控制；主节点可以包括scheduler(调度程序)、apiserver(用户接口服务)、controller-manage(控制器管理)和etcd(分布式kv存储产品)。
26.kubernetes集的从节点可以是node。node上运行着master节点分配的容器组pod，当一个node宕机，其上的pod会被自动转移到其他node上，每一个node节点都安装了node组件，包括kubelet(进程源码)、calico(开源的网络和网络安全方案)、containerd(管理容器的生命周期)和docker(应用容器引擎)等，同时pod还会共享node节点的磁盘、cpu(centralprocessingunit，中央处理器)和内存等硬件资源。
27.其中，kubelet可以用于负责pod的生命周期管理，它监视已分配给节点的pod，同时与master密切协作，维护和管理该node上面的所有容器，以实现集管理的基本功能。即，node节点通过kubelet与master组件交互，可以理解为kubelet是master在每个node节点上面的agent(代理者)。本质上，它负责使pod的运行状态与期望的状态一致。
28.由于组件可以安装在每个kubernetes的node节点上,如果某一组件运行状态异
常，而kubernetes仍然将工作负载调度到当前节点的话会造成异常，影响业务；同样会影响业务的也包括node节点上的硬件(内存、cpu、磁盘)异常。
29.为解决上述问题，本发明提供一种集节点故障处理方案，相比于现有技术，可以实现快速的检测到节点的故障并隔离故障节点，保证业务正常的运行。
30.实施例一
31.图1b为本发明实施例一提供了一种集节点故障处理方法的流程图，本实施例可适用于集节点出现故障进行处理的情况，该方法可以由一种集节点故障处理系统来执行。如图1b所示，该方法包括：
32.s110、通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息。
33.本实施例可以应用于集中的健康节点上，该健康节点可以包括故障检测组件node-agent、故障决策组件node-controller、故障存储组件以及故障处理组件webhook。
34.故障节点中的故障检测组件可以把节点中的故障节点信息上报给故障存储组件。
35.具体的，故障检测组件node-agent可以通过两种方式获取故障节点信息，一是直接从被检测的组件或硬件直接获取故障节点信息，二是调用预设接口(prometheusapi)从其它服务监控系统获取故障节点信息。需要说明的是，被监听的组件可以包括docker组件、kubelet组件、containerd组件以及calico组件等。
36.其中，故障检测组件可以用于配置故障检测场景和多种故障检测方式、端口探活、心跳检测、日志检测、api-server接口获取、prometheus-api获取以及自定义扩展方式。
37.其中，故障存储组件可以用于接收故障节点信息；由于故障检测组件node-agent可以部署在集中每个node节点上；当故障检测组件检测到某节点的组件及硬件发生故障时，可以采用自定义资源crd(custom resourcedefinition，自定义资源)模式将该故障节点信息发送给故障存储组件。自定义资源crd模式可以让开发者自定义资源，因此，crd可以支持通过标准api实现将不同格式的故障信息上报给crd，使故障节点信息上报的方式更丰富，其安装部署简单易用。
38.本实施例中一个集中的任意一个节点上都可以部署自定义资源crd模式，且其它节点知道部署在哪个节点，也可以在多个节点上部署crd，实现高可用性。
39.s120、通过故障决策组件对故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签。
40.本实施例中故障决策组件node-controller可以对故障存储组件中的故障节点信息变化进行监听，故障节点信息变化可以基于已有故障节点的数量上，判断是否出现新增的故障节点。需要说明的是，对于一个集，可以在其任意一个节点上部署故障决策组件node-controller，也可以部署在多个节点上，从而实现高可用性。
41.本实施例中，故障决策组件node-controller可以对故障存储组件中的故障节点信息进行监听；根据监听结果判断故障存储组件中是否有新增的故障节点信息。
42.具体的，故障决策组件node-controller可以包含故障决策单元，其用于基于设定的故障处理策略判断是否根据新增的故障节点信息为对应故障节点设置污点标签。
43.示例性的，设置污点标签的方式可以是调用api-server组件发送污点标签信息，由api-server组件执行设置污点标签的操作。本实施例对此不做具体限制。
44.示例性地，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签，可以包括：在监听到新增的故障节点信息的情况下，通过故障决策组件根据新增的故障节点信息匹配设定的故障处理策略，根据匹配结果判断是否触发为对应故障节点设置污点标签，其中，故障处理策略包含故障场景与故障处理方式的关联关系。
45.其中，设定的故障处理策略可以是对于自动修复类型的故障(例如硬盘或磁盘异常)，则不会触发为对应故障节点设置污点标签，可以直接通过重启的方式对该故障节点进行修复；对于不可自动修复类型的故障，需要为故障节点设置污点标签，同时不允许将新的容器组pod调度到当前设置污点标签的节点；对于不会对当前已有业务容器产生影响的故障，可以只是不允许将新的容器组pod调度到当前设置污点标签的节点。对于影响节点上所有服务的故障，不仅不允许将新的容器组pod调度到当前设置污点标签的节点，还需要将故障节点上的容器组pod驱逐到新节点。
46.本实施例中，故障决策组件可以用于配置不同情况下的故障场景。
47.示例性地，设定的故障处理策略可以包括如下至少一项：在故障节点信息为docker故障的情况下，故障场景为docker组件故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为containerd故障且calico故障的情况下，故障场景为containerd组件与calico组件同时故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为calico故障且kubelet故障的情况下，故障场景为calico组件与kubelet组件同时故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签，且将对应故障节点上的容器组pod驱逐到健康节点；在故障节点信息为kubelet故障的情况下，故障场景为kubelet组件故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为硬件故障的情况下，故障场景为硬件故障触发的节点故障，故障处理方式包括重启故障节点并不为对应故障节点设置污点标签。
48.本实施例中，若故障节点信息为docker故障时，docker某容器hang住，会阻碍docker相关容器接口调度，导致cpu等待时间很长，kubelet和docker心跳失败，进而导致节点notready(死机)，容器会被销毁，因此，需要对对应故障节点设置污点标签以及时隔离该docker故障。
49.本实施例中，若故障节点信息仅仅为containerd故障时，不会对当前已有业务容器产生影响，但会导致关键(calico)容器故障无法重启自愈，因此，在故障节点信息为containerd组件与calico组件同时故障情况下，需要为对应故障节点设置污点标签。
50.本实施例中，若calico组件出现故障或者健康检查失败，kubelet会自动拉起calico容器，保证calico实例一直运行，不影响业务容器；calico容器故障无法正常启动，calico出现故障或者健康检查失败，当kubelet故障的时候，无法保证calico正常重启，calico容器无法正常运行10s后，路由消失，影响节点上所有服务，因此，在故障场景为calico组件与kubelet组件同时故障触发的节点故障，需要为对应故障节点设置污点标签，并将对应故障节点上的容器组pod驱逐到健康节点。
51.本实施例中，若故障节点信息为kubelet故障时，不会影响业务正常运行，因此，对kubelet的故障节点信息检测可以降低敏感度，提升精确度。具体的，可以每秒进行http请求检测(127.0.0.1:10248/healthz)，若连续失败三次则认定当前节点出现kubelet故障，
需要为对应故障节点设置污点标签。
52.本实施例中，若故障节点信息为硬件故障时，包括磁盘未挂载、磁盘损坏或磁盘连接信号质量不稳定、内存读取错误以及磁盘硬件故障，可以重启故障节点并不为对应故障节点设置污点标签。
53.示例性地，通过故障决策组件根据新增的故障节点信息匹配设定的故障处理策略，根据匹配结果判断是否触发为对应故障节点设置污点标签可以包括：通过故障决策组件根据新增的故障节点信息匹配设定的故障处理策略得到故障场景；通过故障决策组件根据故障场景对应的故障处理方式，判断是否触发为对应故障节点设置污点标签。
54.本实施例故障决策组件还可以按照标准配置规则，新增故障场景以及故障场景对应的故障处理方式。
55.本实施例中故障场景可以是docker故障、containerd故障、calico容器故障、kubelet故障以及硬件故障，本实施例对此不做具体限制。
56.本实施例利用故障决策组件可以方便地进行故障场景的配置集中化管理，并且做到检测规则热更新，即，按照标准配置规则，新增故障场景，以及支持动态修改故障处理规则。
57.s130、通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的apiserver组件，故障处理消息用于指示apiserver组件执行故障处理操作。
58.其中，apiserver组件可以是k8s重要的管理api层。它负责提供restfulapi访问端点,并且将数据持久化到etcdserver中。在kubernetes集中，apiserver组件扮演着交互入口的位置。apiserver组件不仅负责和etcd交互(其他组件不会直接操作etcd，只有apiserver组件这么做)，并且对外提供统一的api调用入口,所有的交互都是以apiserver组件为核心的。
59.示例性地，通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的apiserver组件可以包括：在触发为对应故障节点设置污点标签的情况下，通过故障决策组件调用webhook组件发送为故障节点设置污点标签的故障处理消息给主节点的apiserver组件。
60.本实施例中，通过故障决策组件根据判断结果确定是否需要为对应故障节点设置污点标签，若是，则调用故障处理组件webhook发送故障处理消息给主节点中的apiserver组件，由api-server组件执行设置污点标签的操作。
61.本实施例通过故障检测节点快速的对故障节点信息进行检测，再通过故障决策组件对发生故障的节点设置污点标签，以隔离该故障节点，从而保证业务正常的运行，且克服了现有技术中需手动进行故障处理带来的不便，极大程度上节省了时间和人力资源。
62.实施例二
63.图2为本发明实施例二提供的另一种集节点故障处理方法的流程图。在步骤：“通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息”之后，还包括对故障节点信息进行淘汰和过滤。与上述实施例相同的术语在此不赘述。如图2所示，该方法还包括：
64.s210、通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息。
65.s220、在故障节点信息存储在内存的情况下，通过故障存储组件根据故障节点信息的产生时间、存储时间和优先级匹配数据淘汰策略。
66.本实施例中，由于内存本身固有的属性，即，存取速度快，但是可用空间少，因此，故障存储组件需要配置数据淘汰策略对数据进行淘汰。
67.对于根据故障节点信息的产生时间而言，可以保留最新的时间产生的故障节点信息，而淘汰超过预设时间以外的故障节点信息。
68.对于根据故障节点信息的存储时间而言，可以保留存储时间较短，未超过预设时间的故障节点信息，将超过预设时间的故障节点信息淘汰。
69.对于故障节点信息的优先级而言，可以预先为各个故障节点信息设置优先级，将优先级低的故障节点信息淘汰，保留优先级高的故障节点信息。
70.本实施例中，还可以通过文件存储的方式对数据进行存储，因此文件存储可用空间更大，本实施例对此不做具体限制。
71.需要说明的是，可以利用故障决策组件对产生时间、存储时间和优先级的阈值进行设置。
72.s230、通过故障存储组件根据匹配结果对内存中的故障节点信息进行过滤。
73.本实施例中，可以通过故障存储组件根据匹配结果对内存中的故障节点信息进行删除，将故障节点信息产生时间长的或存储时间久的或优先级低的故障节点信息删除。
74.s240、通过故障决策组件对故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签.
75.s250、通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的apiserver组件，故障处理消息用于指示apiserver组件执行故障处理操作。
76.s260、在触发故障节点重启的情况下，通过故障决策组件调用webhook组件发送重启故障节点的故障处理消息给主节点的apiserver组件。
77.本实施例中，对于故障节点信息为硬件故障的情况下，需要进行重启的方式对其进行修复，因此，需要通过故障决策组件调用webhook组件发送重启故障节点的故障处理消息给主节点的apiserver组件，通过主节点的api server组件执行重启操作。
78.本实施例通过对故障节点信息进行淘汰和过滤，节省了内存空间，且利用webhook组件对故障节点信息为硬件故障的情况下进行重启，完善了集节点的自愈能力，使管理员无需手动进行故障处理，极大程度上节省了时间和人力资源。
79.实施例三
80.图3为本发明实施例三提供的又一种集节点故障处理方法的流程图。与上述实施例相同的术语在此不赘述。如图3所示，该方法还包括：
81.s310、通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息。
82.s320、在故障节点信息存储在内存的情况下，通过故障存储组件根据故障节点信息的产生时间、存储时间和优先级匹配数据淘汰策略。
83.s330、通过故障存储组件根据匹配结果对内存中的故障节点信息进行过滤。
84.s340、通过故障决策组件对故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签；
85.s350、通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的apiserver组件，故障处理消息用于指示apiserver组件执行故障处理操作。
86.s260、通过故障存储组件获取集中各个节点的负载信息。
87.本实施例中，需要通过故障存储组件获取集中各个节点的负载信息，通过负载信息可以判断其是否达到最大负载。
88.s370、通过故障决策组件对故障存储组件中的负载信息进行监听，在负载信息满足设定条件时，调用webhook组件发送节点扩容消息给主节点的api server组件。
89.其中，设定条件可以是对负载阈值的设定，可以是90％或100％，本实施例对此不做具体限定，需要说明的是，可以利用故障决策组件对阈值进行设置。
90.本实施例中，故障决策组件node-controller可以支持节点扩容。在整个集达到最大负载的情况下，调用webhook组件发送节点扩容消息给主节点的apiserver组件，以此触发节点扩容。
91.本实施例通过故障决策组件调用webhook组件触发节点扩容，可以自动化的对负载信息进行处理，无需手动进行扩容处理，极大程度上节省了时间和人力资源。
92.实施例四
93.图4为本发明实施例四提供的一种集节点故障处理系统的结构示意图。如图4所示，该系统包括：
94.普通节点401，用于通过故障检测组件获取本节点的组件故障或硬件故障，根据检测结果生成故障节点信息，发送故障节点信息给上述的集节点的故障处理方法的健康节点。
95.其中，故障检测组件node-agent可以通过两种方式获取故障节点信息，一是直接从被检测的组件或硬件直接获取故障节点信息，二是调用预设接口(prometheusapi)从其它服务监控系统获取故障节点信息。
96.健康节点402，用于如上述的集节点的故障处理方法的健康节点；
97.主节点403，用于通过apiserver组件获取所述健康节点发送的故障处理消息，根据故障处理消息确定具有污点标签的故障节点，通过scheduler组件暂停将新的容器组pod调度到具有污点标签的故障节点，或者，在暂停将新的容器组pod调度到具有污点标签的故障节点的基础上，对具有污点标签的故障节点上的已有容器组pod进行驱逐。
98.如图4所示的故障检测组件node-agent可以部署在健康节点和正常节点上，当故障检测组件node-agent检测到该节点出现异常节点时；将故障节点信息上报给图4中的crd，crd可以部署在任意健康节点上；故障决策组件node-controller用于监听crd故障节点信息的变化，其中，故障决策组件node-controller可以包含故障决策单元，用于基于设定的策略决定是否触发为故障节点设置污点标签，设置污点标签的方式是调用api-server组件执行污点标签的设置，同时故障决策组件node-controller的故障决策单元还会视决策调用webhook去做故障的后续处理；通过scheduler组件暂停将新的容器组pod调度到具有污点标签的故障节点，或者，在暂停将新的容器组pod调度到具有污点标签的故障节点的基础上，对具有污点标签的故障节点上的已有容器组pod进行驱逐，以此实现对故障节点的隔离。
99.本实施例中故障检测组件node-agent可以主动检测故障，并使用crd自定义模式
将故障节点信息进行传递，由故障决策组件node-controller处理故障场景，最后触发webhook的多种故障后续处理功能。
100.其中，webhook是一个jar程序，可以引入到自己的java程序中，并扩展化开发webhook做故障的后续处理，具体的，其故障后续处理功能可以包括：对于可自动修复的故障，触发组件重启；对于不可自动修复的故障，触发节点隔离；对于集达到最大负载的情况下，触发节点扩容；对于检测到故障恢复一段时间之后，触发解除报警以及通过webhook记录故障日志。
101.本发明实施例所提供的一种集节点故障处理系统可执行本发明任意实施例所提供的一种集节点故障处理方法，具备执行方法相应的功能模块和有益效果。
102.在本发明中，计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、系统或设备使用或与指令执行系统、系统或设备结合地使用的计算机程序。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、系统或设备，或者上述内容的任何合适组合。备选地，计算机可读存储介质可以是机器可读信号介质。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
103.为了提供与用户的交互，可以在电子设备上实施此处描述的系统和技术，该电子设备具有：用于向用户显示信息的显示系统(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向系统(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向系统来将输入提供给电子设备。其它种类的系统还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
104.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)、区块链网络和互联网。
105.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与vps服务中，存在的管理难度大，业务扩展性弱的缺陷。
106.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。
107.上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明
白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

技术特征：

1.一种集节点的故障处理方法，其特征在于，应用于集中的健康节点，包括：通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息；通过故障决策组件对所述故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签；通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的api server组件，所述故障处理消息用于指示api server组件执行故障处理操作。2.根据权利要求1所述的方法，其特征在于，所述根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签，包括：在监听到新增的故障节点信息的情况下，通过故障决策组件根据所述新增的故障节点信息匹配设定的故障处理策略，根据匹配结果判断是否触发为对应故障节点设置污点标签，其中，故障处理策略包含故障场景与故障处理方式的关联关系。3.根据权利要求2所述的方法，其特征在于，所述设定的故障处理策略包括如下至少一项：在故障节点信息为docker故障的情况下，故障场景为docker组件故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为containerd故障且calico故障的情况下，故障场景为containerd组件与calico组件同时故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为calico故障且kubelet故障的情况下，故障场景为calico组件与kubelet组件同时故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签，且将对应故障节点上的容器组pod驱逐到健康节点；在故障节点信息为kubelet故障的情况下，故障场景为kubelet组件故障触发的节点故障，故障处理方式包括为对应故障节点设置污点标签；在故障节点信息为硬件故障的情况下，故障场景为硬件故障触发的节点故障，故障处理方式包括重启故障节点并不为对应故障节点设置污点标签。4.根据权利要求3所述的方法，其特征在于，所述通过故障决策组件根据所述新增的故障节点信息匹配设定的故障处理策略，根据匹配结果判断是否触发为对应故障节点设置污点标签，包括：通过故障决策组件根据所述新增的故障节点信息匹配设定的故障处理策略得到故障场景；通过故障决策组件根据所述故障场景对应的故障处理方式，判断是否触发为对应故障节点设置污点标签。5.根据权利要求1所述的方法，其特征在于，所述通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的api server组件，包括：在触发为对应故障节点设置污点标签的情况下，通过故障决策组件调用webhook组件发送为故障节点设置污点标签的故障处理消息给所述主节点的api server组件。6.根据权利要求1所述的方法，其特征在于，还包括：在触发故障节点重启的情况下，通过故障决策组件调用webhook组件发送重启故障节点的故障处理消息给所述主节点的api server组件。
7.根据权利要求1所述的方法，其特征在于，在通过故障存储组件获取异常节点采用自定义资源crd模式上报的故障节点信息之后，还包括：在所述故障节点信息存储在内存的情况下，通过故障存储组件根据故障节点信息的产生时间、存储时间和优先级匹配数据淘汰策略；通过故障存储组件根据匹配结果对所述内存中的故障节点信息进行过滤。8.根据权利要求1所述的方法，其特征在于，还包括：通过故障存储组件获取集中各个节点的负载信息；通过故障决策组件对所述故障存储组件中的负载信息进行监听，在所述负载信息满足设定条件时，调用webhook组件发送节点扩容消息给所述主节点的api server组件。9.一种集节点的故障处理系统，其特征在于，包括：普通节点，用于通过故障检测组件获取本节点的组件故障或硬件故障，根据检测结果生成故障节点信息，发送故障节点信息给执行如权利要求1-8中任一项所述的集节点的故障处理方法的健康节点；所述健康节点，用于如权利要求1-8中任一项所述的集节点的故障处理方法的健康节点；主节点，用于通过api server组件获取所述健康节点发送的故障处理消息，根据所述故障处理消息确定具有污点标签的故障节点，通过scheduler组件暂停将新的容器组pod调度到具有污点标签的故障节点，或者，在暂停将新的容器组pod调度到具有污点标签的故障节点的基础上，对具有污点标签的故障节点上的已有容器组pod进行驱逐。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使处理器执行时实现权利要求1-8中任一项所述的集节点的故障处理方法。

技术总结

本发明实施例公开了一种集节点故障处理方法、系统及介质。该方法包括：通过故障存储组件获取异常节点采用自定义资源CRD模式上报的故障节点信息；通过故障决策组件对故障存储组件中的故障节点信息进行监听，根据新增的故障节点信息判断是否触发为对应故障节点设置污点标签；通过故障决策组件根据判断结果调用故障处理组件发送故障处理消息给主节点中的Apiserver组件，故障处理消息用于指示Apiserver组件执行故障处理操作。本实施例可以快速的检测到集中发生故障的节点并通过设置污点标签隔离该故障节点，从而保证了业务正常的运行。正常的运行。正常的运行。