基于BMC的Kubernetes集群物理节点的故障处理方法和系统与流程

基于bmc的kubernetes集群物理节点的故障处理方法和系统
技术领域
1.本技术涉及云原生技术领域，特别涉及一种基于bmc的kubernetes集群物理节点的故障处理方法、系统、计算机可读存储介质和电子设备。


背景技术：

2.现有相关技术中，kubernetes集群节点的故障处理方法为：通过每个节点上容器化部署的kubelet组件，对所在节点进行状态监测，并将所在节点的状态信息上报。这实质上是一种基于软件的监测方法，将该方法用于物理节点的状态监测，当kubelet组件正常运行所依赖的操作系统或者其他底层技术出现故障时，kubelet组件将无法正常工作，master(控制)节点将无法获得kubelet组件所在节点的任何状态信息，整个监测系统处于失灵状态。此外，当物理节点因硬件问题存在某些底层故障风险时，这些底层故障风险无法被kubelet组件感知，也不会上报给master节点，相应地，master节点将无法针对故障风险采取相应措施进行处理。
3.因此，如何全面监测kubernetes集群物理节点中存在的风险或者故障，并对物理节点及时进行相应地处理，以保障kubernetes集群中物理节点上的应用可靠运行，成为kubernetes集群管理中亟待解决的问题。


技术实现要素：

4.本技术的目的在于提供一种基于bmc的kubernetes集群物理节点的故障处理方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。
5.为了实现上述目的，本技术提供如下技术方案：
6.本技术提供了一种基于bmc的kubernetes集群物理节点的故障处理方法，包括：从物理节点上设置的bmc中获取所述物理节点的第一状态信息；其中，所述第一状态信息表征所述物理节点的硬件运行状态和操作系统运行状态；
7.根据所述第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的所述物理节点进行处理。
8.在本技术的任一可选实施例中，所述从物理节点上设置的bmc中获取所述物理节点的第一状态信息，具体为：
9.对所述物理节点上设置的bmc进行注册，建立基于监控协议的通讯连接，以按照预设监控周期访问所述物理节点上的已注册的bmc，获取所述物理节点的第一状态信息。
10.在本技术的任一可选实施例中，根据所述第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的所述物理节点进行处理，包括：
11.根据所述第一状态信息，判定所述物理节点存在风险或者故障的类型；
12.根据所述风险或者故障的类型，基于预设的所述自定义控制策略，对所述物理节点进行处理。
13.在本技术的任一可选实施例中，所述根据所述第一状态信息，判定所述物理节点
存在风险或者故障的类型，包括：
14.在预设周期内未收到部署在所述物理节点上的kubelet组件上报的所述物理节点的第二状态信息时，根据所述第一状态信息表征的所述物理节点的硬件运行状态和操作系统运行状态，判定所述物理节点存在宕机故障；其中，所述第二状态信息表征所述物理节点上的节点运行状态和容器运行状态。
15.在本技术的任一可选实施例中，在所述根据所述第一状态信息表征的所述物理节点的硬件运行状态和操作系统运行状态，判定所述物理节点存在宕机故障之后，还包括：
16.从所述物理节点上设置的bmc中获取所述物理节点的运行日志信息；
17.对所述物理节点的运行日志信息进行分析，以确定所述物理节点发生宕机故障的原因；
18.根据所述物理节点发生宕机故障的原因，指示所述物理节点上设置的bmc对所述物理节点进行重启操作。
19.在本技术的任一可选实施例中，所述根据所述第一状态信息，判定所述物理节点存在风险或者故障的类型，包括：
20.对所述第一状态信息进行分析，以评估部署在所述物理节点上的应用因所述物理节点存在风险或者故障所受到的影响；
21.根据部署在所述物理节点上的应用所受到的影响，划分所述物理节点存在风险或者故障的类型。
22.在本技术的任一可选实施例中，所述根据所述风险或者故障的类型，基于预设的所述自定义控制策略，对所述物理节点进行处理，具体为：
23.对存在风险的所述物理节点标注风险标签；其中，所述风险标签包括多个等级，所述风险标签的等级与所述风险的类型相关；或者，
24.对存在故障的所述物理节点标注故障标签；其中，所述故障标签包括多个类别，所述故障标签的类别与所述故障的类型相关。
25.本技术实施例还提供一种基于bmc的kubernetes集群物理节点的故障处理系统，包括：
26.信息获取单元，配置为从物理节点上设置的bmc中获取所述物理节点的第一状态信息；其中，所述第一状态信息表征所述物理节点的硬件运行状态和操作系统运行状态；
27.策略执行单元，配置为根据所述第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的所述物理节点进行处理。
28.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序为上述任一所述的基于bmc的kubernetes集群物理节点的故障处理方法。
29.本技术实施例还提供一种电子设备，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上述任一所述的基于bmc的kubernetes集群物理节点的故障处理方法。
30.与最接近的现有技术相比，本技术实施例的技术方案具有如下有益效果：
31.本技术中，通过控制节点从kubernetes集群的物理节点上设置的bmc中获取物理节点的第一状态信息；其中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态；然后，控制节点根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故
障的物理节点进行处理。藉此，控制节点主动对物理节点的硬件运行状态和操作系统运行状态进行实时监控，有效解决现有技术中风险或者故障监控不全面、不及时的问题。并在监控到物理节点存在故障或者风险后，根据预设的自定义控制策略对物理节点及时进行相应地处理，以提升物理节点的可靠性，实现物理节点上应用的高可用。
附图说明
32.构成本技术的一部分的说明书附图用来提供对本技术的进一步理解，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。其中：
33.图1为现有的kubernetes集群节点的故障处理的流程示意图；
34.图2为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理方法的流程示意图；
35.图3为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理方法的工作原理图；
36.图4为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理系统的结构示意图；
37.图5为根据本技术的一些实施例提供的电子设备的结构示意图；
38.图6为根据本技术的一些实施例提供的电子设备的硬件结构。
具体实施方式
39.下面将参考附图并结合实施例来详细说明本技术。各个示例通过本技术的解释的方式提供而非限制本技术。实际上，本领域的技术人员将清楚，在不脱离本技术的范围或精神的情况下，可在本技术中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本技术包含归入所附权利要求及其等同物的范围内的此类修改和变型。
40.参见图1，图1为现有的kubernetes集群节点的故障处理的流程示意图。现有技术中，kubernetes集群基于软件的监测方法，通过kubernetes系统原生的kubelet组件和scheduler组件来处理集群中节点的故障。具体来说，kubernetes集群中节点上的kubelet组件每隔一段时间，通过网络向master(控制)节点上的api-server组件上报所在节点的状态信息。如果kubelet组件上报的状态信息显示该节点的状态存在故障，或者，master节点超过预设时长未收到某节点上的kubelet组件上报的状态信息，则scheduler组件根据存储在etcd中的该节点上的pod(容器组)信息，将该节点上的全部pod调度至其他健康节点上。
41.将前述基于软件的监测方法用于kubernetes集群物理节点的故障处理至少存在如下不足：
42.一是容易因误判导致错误调度：当master节点超过预设时长未收到某物理节点上的kubelet组件上报的状态信息时，既可能是kubelet组件所在物理节点与master节点之间的网络出现抖动或者故障，也可能是kubelet组件所在物理节点出现故障，因此该方案存在一定的可能将网络故障误判为物理节点故障，错误地将正常物理节点上pod调走。
43.二是故障处理不及时：当某物理节点出现故障时，需要立即将该物理节点上pod在其他健康物理节点上重新部署，保证pod对外提供服务的可靠性。现有技术为了降低将网络
故障误判为物理节点故障的可能性，引入了延迟判定机制，即master(控制)节点上的api-server组件没有在预定时间收到kubelet组件上报所在物理节点的状态信息，不会立即将该物理节点判定为故障节点，而是继续等待kubelet组件的下一次上报，直至超过预设最大时长仍没有收到kubelet组件上报所在物理节点的状态信息，才会将该物理节点判定为故障节点。因此，在物理节点出现故障且kublet组件已经向master节点上报了所在物理节点存在故障的信息的情况下，如果kubelet组件上报所在物理节点存在故障的信息时因网络抖动而出现丢失，无法到达master节点，则master节点会在不超过预设最大时长的时间段内持续等待kubelet组件上报所在物理节点的状态信息。在kubelet组件上报所在物理节点存在故障的信息成功到达master节点后，才将该物理节点判定为故障节点，对故障节点上的pod进行调度，造成故障节点上pod的调度产生延迟，pod在较长时间内无法对外正常提供服务。
44.三是无法处理严重故障：当物理节点存在操作系统故障或者宕机等严重问题时，kubelet组件将无法正常运行，也就无法对所在物理节点的状态信息进行上报，使得master节点无法获知该物理节点的状态信息，也就无法确定物理节点故障的原因，更无法解决该物理节点的故障，使其恢复正常。
45.四是无法处理物理节点因硬件存在的风险：当物理节点因硬件问题存在底层故障风险时，有些故障风险会对特定上层应用造成一定影响，有些故障风险虽不会影响上层应用的正常运行，但却会降低物理节点的整体可靠性，而这些故障风险都无法被kubelet组件感知，也就不会上报给master节点，master节点不会就故障风险采取相应措施进行处理。
46.为了解决上述问题，本技术提供一种基于bmc的kubernetes集群物理节点的故障处理方法。图2为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理方法的流程示意图；图3为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理方法的工作原理图；如图2、图3所示，该基于bmc的kubernetes集群物理节点的故障处理方法包括：
47.步骤s101、从物理节点上设置的bmc中获取物理节点的第一状态信息。
48.其中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态。
49.bmc(baseboard management controller，基板管理控制器)为专用的服务处理机，其通过传感器和其他技术手段，监控计算机、服务器，或者其他硬件驱动设备的状态。现有技术中，当bmc监控到计算机、服务器，或者其他硬件驱动设备出现故障时，比如电源时序、风扇控制、raid配置等故障，通过向管理员发出告警信息以提醒管理员进行处理，并根据接收到的管理员指令对监控对象进行相应的处理，也就是说，现有的bmc虽然能够监控计算机、服务器，或者其他硬件驱动设备的运行状态并在出现异常情况时发出告警信息，但是无法对故障进行自动判断和自动处理，仍然需要管理员人工对故障进行处理，而且延误了故障处理时间。
50.本技术实施例中，图3所示，kubernetes集群包括多个物理节点，根据功能不同，具体可以分为控制节点和工作节点，bmc设置在kubernetes集群的每个物理节点上，且独立于物理节点，可以理解地，bmc作为相对于物理节点独立的系统，能够不依赖于物理节点上的cpu、内存等其他硬件而运行。藉此，通过在物理节点上布置独立于该节点的bmc，当物理节点出现操作系统故障或因硬件故障导致应用无法正常运行时，bmc因独立于物理节点上的
硬件和操作系统运行，仍然能够正常获取所在物理节点的第一状态信息，从而解决基于kubelet组件进行监控时，因无法及时获知操作系统故障或者硬件故障等严重问题，进而导致的无法及时解决该物理节点的故障的问题。
51.本技术实施例中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态，上述状态信息均为基于kubelet组件的软件监测方法无法获取或者无法及时获知的状态信息。具体地，物理节点上布置有传感器，bmc通过物理节点上预设的传感器，监测所在物理节点的硬件运行状态。可以理解地，预设的传感器可以收集的硬件信息包括但不限于：硬件温度、风扇转速、电压、电源状态、机箱入侵。对应地，第一状态信息包括bmc获取的传感器监测得到的电扇、电源、机箱等外部硬件状态信息。此外，第一状态信息还可以包括bmc获取的操作系统状态信息，即bmc可以直接访问物理节点的bios获取的cpu、内存、存储等其他硬件状态信息和操作系统状态信息，以反映物理节点上的应用正常运行所依赖的底层操作系统的运行状态。
52.本技术实施例中，通过bmc获取物理节点上的传感器获取硬件运行状态和bmc直接访问物理节点上bios获取物理节点的操作系统运行状态和其他硬件的运行状态，以对传统的节点的故障处理中基于kubelet组件的软件监控方法形成有效的补充，使得物理节点的运行状态信息获取更加完整、全面、及时，为后续进一步采取相应的措施提供了基础。
53.在一些可选实施例中，从物理节点上设置的bmc中获取物理节点的第一状态信息，具体为：对物理节点上设置的bmc进行注册，建立基于监控协议的通讯连接，以按照预设监控周期访问物理节点上的已注册的bmc，获取物理节点的第一状态信息。
54.现有技术中，kubernetes集群的相关组件无法自动访问部署在物理节点上的bmc，从而无法及时获取bmc监控到的各类运行状态信息，无法充分利用bmc的功能特性。为了解决上述问题，本技术实施例中，对kubernetes集群中的控制节点上的operator组件进行扩展，作为核心控制器，并由核心控制器对物理节点上设置的bmc进行注册，建立基于监控协议的通讯连接，以按照预设监控周期访问物理节点上的已注册的bmc，获取物理节点的第一状态信息。
55.在一些可选实施例中，核心控制器对物理节点上设置的bmc进行注册，具体为：核心控制器对物理节点上设置的bmc的访问ip和访问密码进行注册，建立基于监控协议的通讯连接，以允许核心控制器按照预设监控周期访问物理节点上设置的bmc，获取物理节点的第一状态信息。可以理解，监控协议可以为redfish api协议、ipmi协议等能够传输物理节点的状态信息的协议。
56.具体地，核心控制器包括：operator组件。operator组件为kubernetes集群中感知应用状态的控制器，其通过扩展kubernetes api来自动创建、管理和配置应用实例，operator组件能够基于第三方资源扩展新的应用资源，并通过控制器来保证应用处于预期状态。本技术实施例中，operator组件用于对物理节点上设置的bmc进行注册，并主动访问每个物理节点上已注册的bmc，获取物理节点的第一状态信息。详细来说，对物理节点上设置的bmc进行注册时，由operator组件对每个物理节点上的bmc的访问ip和访问密码进行注册，建立基于redfish api或者ipmi协议的通讯，并按照预设监控周期访问物理节点上的已注册的bmc，进行周期性的信息收集，以获取物理节点的第一状态信息。
57.通过对kubernetes集群中的控制节点上的operator组件进行扩展，作为核心控制
器，对物理节点上设置的bmc进行注册，使得核心控制器能够周期性访问物理节点上的bmc，以及时获取物理节点的第一状态信息。藉此，充分利用bmc能够独立于物理节点，对硬件运行状态和操作系统运行状态进行持续、自动监控的功能特性，进而使kubernetes集群及时、全面、准确掌握物理节点运行状态，以此为依据制定、执行相应的处理策略。
58.步骤s102、根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理。
59.本技术实施例中，预设的自定义控制策略指的是用户预先定义的、针对物理节点不同的风险或故障状态而采取的控制策略，比如，针对物理节点宕机，可以对物理节点进行重启，或者，将物理节点上的应用调度到其他物理节点。
60.本技术实施例中，预设的自定义控制策略通过控制节点上的核心控制器实现，具体地，核心控制器包括：策略自定义资源(policy crd)，策略自定义资源为用户提供进行自定义策略的途径，以预先定义物理节点存在风险或者故障时指示核心控制器执行的相应控制策略。
61.本技术实施例中，核心控制器还包括扩展的scheduler插件，用于执行预设的自定义控制策略。具体来说，scheduler插件通过对原有的kubernetes的调度逻辑进行扩展得到，其能够基于预设的自定义控制策略的指示，根据第一状态信息，对存在风险或者故障的物理节点进行自动处理。
62.在一些可选实施例中，控制节点根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理，包括：控制节点根据第一状态信息，判定物理节点存在风险或者故障的类型；根据风险或者故障的类型，基于预设的自定义控制策略，对物理节点进行处理。藉此，通过核心控制器的策略自定义资源为物理节点上存在风险或者故障提供自动处理策略，进而根据该自动处理策略，对存在风险或者故障进行自动处理，避免人工操作，提高了处理效率，并降低了处理出错风险。
63.进一步地，根据第一状态信息，判定物理节点存在风险或者故障的类型，包括：对第一状态信息进行分析，以评估部署在物理节点上的应用因物理节点存在风险或者故障所受到的影响；根据部署在物理节点上的应用所受到的影响，划分物理节点存在风险或者故障的类型。对应地，根据风险或者故障的类型，基于预设的自定义控制策略，对物理节点进行处理，具体为：对存在风险的物理节点标注风险标签；其中，风险标签包括多个等级，风险标签的等级与风险的类型相关；或者，对存在故障的物理节点标注故障标签；其中，故障标签包括多个类别，故障标签的类别与故障的类型相关。根据物理节点的标注，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理。
64.本技术实施例中，在获取第一状态信息之后、对第一状态信息进行分析，以评估部署在物理节点上的应用因物理节点存在风险或者故障所受到的影响之前，还包括：标注物理节点上每个应用运行所需使用的硬件资源，以建立应用与所需硬件之间的映射关系，并将其存储在自定义资源或者etcd中。
65.在又一具体场景中，当控制节点通过对第一状态信息进行分析，确定物理节点部分硬件发生异常，也就是说，物理节点因硬件问题存在风险，并且，该风险无法被现有的基于软件的监测方法所感知，则根据风险对应的硬件，基于预先建立的应用与所需硬件之间的映射关系，评估部署在物理节点上的应用因物理节点存在风险或者故障所受到的影响，
并根据部署在物理节点上的应用所受到的影响，划分物理节点存在风险或者故障的类型。
66.进一步地，控制节点对第一状态信息进行分析，确定物理节点发生部分硬件异常，导致物理节点整体性能下降出现风险，比如，物理节点上的双冗余电源中的一个电源失灵，此时仍有剩余另一个电源正常运行，能够为物理节点正常供电，但若剩余的另一个电源也出现故障，则整个物理节点将彻底断电，因此，双冗余电源中的一个电源失灵导致物理节点的故障可能性升高；又比如，物理节点的多个风扇中的部分风扇存在故障，剩余的风扇虽然正常运行，并未影响物理节点正常运行，但由于部分风扇故障，剩余的风扇处于高负荷运转状态，导致物理节点可能出现温度过高，进而故障可能性升高；再比如，物理节点上的内存、pci设备、低速io芯片和设备等存在局部故障，在bmc的系统日志中将记录有“warning”(警告级别的)日志信息，但在操作系统层面仍可正常运行，对应用的运行没有造成影响。此时，控制节点根据对第一状态信息进行分析，判定上述硬件风险对物理节点上的应用并未产生影响，确定物理节点上的风险类型为：轻微风险，该类型风险对应的风险标签的等级为亚健康。当轻微风险发生时，kubelet组件无法监测到上述风险，控制节点充分利用bmc独立于物理节点的功能特性，访问bmc获取第一状态信息，获知该物理节点存在轻微风险，进而降低该物理节点的调度优先级和评分，从而使应用优先部署到其他物理节点上。具体来说，由operator组件通过对获取的第一状态信息进行分析，确定物理节点因部分硬件异常存在整体性能下降的风险，根据预先建立的应用与所需硬件之间的映射关系，判断该风险并未影响物理节点上的应用正常运行时，则operator组件对该物理节点标注亚健康标签，以反映该物理节点整体性能下降、发生故障的可能性升高的状态。scheduler插件根据物理节点对应的风险标签的等级，基于预设的自定义控制策略，在为应用选择部署的物理节点时，对具有不同等级的风险标签的物理节点的评分进行相应的减分计算，并将应用部署在集群中评分最高的物理节点上，从而使应用优先部署到其他物理节点上。
67.本技术实施例中，当物理节点的部分硬件出现异常导致物理节点存在风险，而基于软件监测方法无法监测到该异常时，通过对bmc及时获取第一状态信息，并对其进行分析，然后基于预设的自定义控制策略，进行及时、有效地应对，减少了物理节点风险带来的影响。
68.在又一场景中，控制节点对第一状态信息进行分析，当确定物理节点发生局部硬件故障时，则根据发生局部硬件故障的类型，对存在故障的物理节点标注不同类别的故障标签。比如，物理节点上的raid卡管理的磁盘或者pcie的外部存储卡出现局部故障，根据预先建立的应用与所需硬件之间的映射关系，确定该类局部故障只会对本地存储的有状态应用、使用外部存储卡的应用造成影响，对于其他类型的应用没有影响，可以对该物理节点标注存储故障标签；又比如，物理节点上的gpu出现故障，根据预先建立的应用与所需硬件之间的映射关系，确定该故障只会对图像处理、人工智能相关应用造成影响，对于其他不使用gpu的应用没有影响，可以对该物理节点标注gpu故障标签。此时，控制节点根据对第一状态信息进行分析，判断上述局部硬件故障对物理节点上的部分应用产生影响，对存在局部硬件故障的物理节点标注相应类别的故障标签。kubelet组件无法监测到上述风险，基于bmc独立于物理节点的功能特性，控制节点仍然能够访问bmc获取第一状态信息，获知该物理节点存在局部硬件故障，进而将物理节点上受影响的应用调度至其他物理节点上，并拒绝相应类型的应用部署在该物理节点上。具体地，由operator组件通过对获取的第一状态信息
进行分析，确定物理节点上的部分硬件存在故障，根据预先建立的应用与所需硬件之间的映射关系，判断该局部硬件故障对相应类型的应用产生影响时，operator组件对该物理节点标注相应类别的故障标签(即自定义的污点标签)，以反映该物理节点发生异常的硬件无法对相应类型的应用提供服务。scheduler插件根据物理节点被标注的故障标签，基于预设的自定义控制策略，在为相应类型的应用选择部署的物理节点时，先将具有相应类别的故障标签的物理节点从备选节点中预先筛除，再对剩余的物理节点进行评分计算，将应用部署在集群中评分最高的物理节点上，从而拒绝相应类型的应用部署在该物理节点上。
69.本技术实施例中，针对物理节点上出现局部硬件故障的类型，根据应用与硬件资源之间的映射关系，对不同类型的局部硬件故障进行分别处理，提高了集群管理中对局部硬件故障管理的针对性，并使得物理节点上的调度策略更加精细合理。
70.在又一可选实施例中，根据第一状态信息，判定物理节点存在风险或者故障的类型，包括：在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，根据第一状态信息表征的物理节点的硬件运行状态和操作系统运行状态，判定物理节点存在宕机故障。其中，第二状态信息表征物理节点上的节点运行状态和容器运行状态。
71.具体地，当物理节点因cpu故障、内存故障、操作系统故障发生宕机时，kubelet组件因物理节点的故障无法正常运行，在预设周期内无法向master节点上报物理节点的第二状态信息，master节点上的核心控制器通过operator组件主动访问该物理节点上的bmc，bmc通过直接检测物理节点上的bios看门狗的状态，确定物理节点处于宕机状态，operator组件对该物理节点标注宕机故障标签。
72.进一步地，在根据第一状态信息表征的物理节点的硬件运行状态和操作系统运行状态，判定物理节点存在宕机故障之后，还包括：从物理节点上设置的bmc中获取物理节点的运行日志信息；对物理节点的运行日志信息进行分析，以确定物理节点发生宕机故障的原因；根据物理节点发生宕机故障的原因，基于预设的自定义控制策略，指示物理节点上设置的bmc对物理节点进行重启操作。
73.本技术实施例中，在确定物理节点处于宕机状态之后，控制节点上的核心控制器首先通过operator组件从物理节点上设置的bmc中获取物理节点的运行日志信息，对bmc的系统日志中记录的物理节点的运行日志信息进行分析，以确定物理节点发生宕机故障的原因，然后根据物理节点发生宕机故障的原因，对物理节点进行相应的处理：当判断物理节点的宕机故障仅需对物理节点进行系统复位即可恢复，则根据核心控制器中预设的控制策略中配置的“自动恢复”功能，指示物理节点上设置的bmc对物理节点进行重启操作。当判断物理节点进行重启操作无法恢复正常时，则根据预设的自定义控制策略中配置的调度策略，将该物理节点上运行的应用调度至健康的物理节点上，如果在执行应用调度时没有空闲的健康节点可以调度，则将备用节点纳入kubernetes集群管理，将应用调度至备用节点上。
74.本技术实施例中，由scheduler插件根据operator组件判断的物理节点所处的状态和预设的自定义控制策略，对存在风险或者故障的物理节点进行自动处理。比如，当operator组件判断物理节点发生宕机故障，并对bmc上的物理节点的运行日志信息进行分析，得到的物理节点发生宕机故障的原因后，scheduler插件根据宕机故障的原因和预设的自定义控制策略中的“自动恢复”功能或者调度策略的指示，进行自动处理。具体地，当判断
物理节点通过重启能够恢复正常时，scheduler插件通过bmc对物理节点进行重启操作。当判断物理节点不能通过重启恢复正常时，scheduler插件根据调度策略，将物理节点上的应用调度至健康的物理节点。
75.本技术实施例中，当物理节点发生宕机或者操作系统故障等严重问题时，kubelet组件将无法对上述故障状态信息进行上报。此时，控制节点通过bmc获取第一状态信息，能够及时获知物理节点的运行状态，并通过对第一状态信息的分析，确定物理节点故障的原因，进而及时进行自动处理，从而解决该物理节点的故障，使其快速恢复正常。
76.需要说明的是，当控制节点在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，并不一定都是因为物理节点存在宕机故障，还需要根据物理节点的第一状态信息，进行相应地处理。比如下面两种具体场景：
77.在一具体场景中，当控制节点在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，控制节点同样无法从物理节点上的bmc获取第一状态信息，则判定该物理节点出现电源故障，物理节点上的所有应用均受到严重影响。此时控制节点确定该物理节点的故障的类型为电源故障，并对该物理节点标注电源故障标签。具体地，当控制节点在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，控制节点上的operator组件主动访问物理节点上的bmc，发现同样无法从物理节点上的bmc获取第一状态信息，则说明物理节点出现了电源故障，此时，该物理节点上的所有应用均受到影响，operator组件对该物理节点标注电源故障标签。scheduler插件根据物理节点对应的电源故障标签，基于预设的自定义控制策略，将该物理节点上运行的应用调度至健康节点，如果没有空闲的健康节点可以调度，则将备用节点纳入kubernetes集群管理，将该物理节点上的应用调度至备用节点。
78.在又一具体场景中，当控制节点在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，控制节点从物理节点上的bmc获取第一状态信息，对第一状态信息进行分析，确定物理节点不存在任何风险和故障，故障类型为网络故障，物理节点上的所有应用均不会受到影响，则控制节点对该物理节点标注网络故障标签。具体地，当控制节点中的operator组件在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，控制节点上的operator组件主动访问物理节点上的bmc，从物理节点上的bmc获取第一状态信息，对第一状态信息进行分析，确定该物理节点的操作系统运行正常，kubelet组件是因网络故障而与控制节点暂时失去联系，则operator组件对该物理节点标注网络故障标签。scheduler插件根据物理节点对应的网络故障标签，基于预设的自定义控制策略，对物理节点上的应用不进行调度，维持原状，等待网络恢复。藉此，当控制节点无法及时获取物理节点上的第二状态信息时，通过bmc获取的第一状态信息对物理节点的运行状态进行确认，以避免对物理节点的运行状态发生误判，进而防止将健康的物理节点上的应用进行调度，节约了系统资源。
79.可以理解地，除了上述列举的风险或者故障类型之外，本技术的技术方案还可以处理物理节点上其他类型的风险或者故障。具体地，当需要处理新的故障或者风险类型时，针对新的故障或者风险类型，通过核心控制器对控制策略进行定义，进而由核心控制器根据自定义的控制策略，对新的故障或者风险类型进行相应处理。
80.本技术实施例中，通过bmc获取物理节点的硬件运行状态和操作系统运行状态，通
过kubelet组件获取物理节点上的节点运行状态和容器运行状态，为kubernetes集群提供了全面、及时的运行状态信息，kubernetes集群通过对控制节点扩展，根据所获取的物理节点运行状态信息，对物理节点的故障或者风险进行自动处理，从而解决了现有技术中对物理节点的运行状态监控不全面、不及时、无法自动处理故障的问题，节约了人工成本，提高了处理效率。
81.本技术实施例中，通过对kubernetes集群中的控制节点上的operator组件进行扩展，作为核心控制器，对物理节点上设置的bmc进行注册，使得核心控制器能够周期性访问物理节点上的bmc，以及时获取物理节点的第一状态信息。藉此，充分利用bmc能够独立于物理节点，对硬件运行状态和操作系统运行状态进行持续、自动监控的功能特性，进而使kubernetes集群及时、全面、准确掌握物理节点运行状态，以此为依据制定、执行相应的处理策略。
82.本技术实施例中，通过bmc获取的物理节点运行状态信息，确定物理节点出现宕机故障时，根据预设的自定义控制策略，指示bmc对发生宕机故障的物理节点进行自动重启，使得该物理节点能够及时恢复。
83.示例性系统
84.图4为根据本技术的一些实施例提供的一种基于bmc的kubernetes集群物理节点的故障处理系统的结构示意图；如图4所示，该系统包括：信息获取单元401和策略执行单元402，信息获取单元401，配置为从物理节点上设置的bmc中获取物理节点的第一状态信息；其中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态；策略执行单元402，配置为根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理。
85.在一些可选实施例中，信息获取单元401进一步配置为：对物理节点上设置的bmc进行注册，建立基于监控协议的通讯连接，以按照预设监控周期访问物理节点上的已注册的bmc，获取物理节点的第一状态信息。
86.在一些可选实施例中，策略执行单元402进一步配置为：根据第一状态信息，判定物理节点存在风险或者故障的类型；根据风险或者故障的类型，基于预设的自定义控制策略，对物理节点进行处理。
87.在一些可选实施例中，根据第一状态信息，判定物理节点存在风险或者故障的类型，包括：在预设周期内未收到部署在物理节点上的kubelet组件上报的物理节点的第二状态信息时，根据第一状态信息表征的物理节点的硬件运行状态和操作系统运行状态，判定物理节点存在宕机故障；其中，第二状态信息表征物理节点上的节点运行状态和容器运行状态。
88.在一些可选实施例中，在根据第一状态信息表征的物理节点的硬件运行状态和操作系统运行状态，判定物理节点存在宕机故障之后，还包括：从物理节点上设置的bmc中获取物理节点的运行日志信息；对物理节点的运行日志信息进行分析，以确定物理节点发生宕机故障的原因；根据物理节点发生宕机故障的原因，指示物理节点上设置的bmc对物理节点进行重启操作。
89.在一些可选实施例中，根据第一状态信息，判定物理节点存在风险或者故障的类型，包括：对第一状态信息进行分析，以评估部署在物理节点上的应用因物理节点存在风险
或者故障所受到的影响；根据部署在物理节点上的应用所受到的影响，划分物理节点存在风险或者故障的类型。
90.在一些可选实施例中，根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理，具体为：对存在风险的物理节点标注风险标签；其中，风险标签包括多个等级，风险标签的等级与风险的类型相关；或者，对存在故障的物理节点标注故障标签；其中，故障标签包括多个类别，故障标签的类别与故障的类型相关。
91.本技术实施例提供的基于bmc的kubernetes集群物理节点的故障处理系统能够实现上述任一基于bmc的kubernetes集群物理节点的故障处理方法实施例的步骤、流程，并达到相同的有益效果，在此不再一一赘述。
92.示例性设备
93.图5为根据本技术的一些实施例提供的电子设备的结构示意图；如图5所示，该电子设备包括：
94.一个或多个处理器501；
95.计算机可读介质，可以配置为存储一个或多个程序502，一个或多个处理器501执行一个或多个程序502时，实现如下步骤：
96.从物理节点上设置的bmc中获取物理节点的第一状态信息；其中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态；根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理。
97.图6为根据本技术的一些实施例提供的电子设备的硬件结构，如图6所示，该电子设备的硬件结构可以包括：处理器601、通信接口602、计算机可读介质603和通信总线604。
98.其中，处理器601、通信接口602、计算机可读介质603通过通信总线604完成相互间的通信。
99.可选地，通信接口602可以为通信模块的接口，如gsm模块的接口。
100.其中，处理器601具体可以配置为：
101.从物理节点上设置的bmc中获取物理节点的第一状态信息；其中，第一状态信息表征物理节点的硬件运行状态和操作系统运行状态；根据第一状态信息，基于预设的自定义控制策略，对存在风险或者故障的物理节点进行处理。
102.处理器可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等，还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
103.本技术实施例的电子设备以多种形式存在，包括但不限于：
104.(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iphone)、多媒体手机、功能性手机，以及低端手机等。
105.(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：pda、mid和umpc设备等，例如ipad。
106.(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、
视频播放器(例如：ipod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。
107.(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
108.(5)其他具有数据交互功能的电子装置。
109.需要指出，根据实施的需要，可将本技术实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本技术实施例的目的。
110.上述根据本技术实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如cd rom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，ram、rom、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的基于bmc的kubernetes集群物理节点的故障处理方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。
111.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术实施例的范围。
112.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
113.以上所述仅为本技术的优选实施例，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。