CN114942859A - 节点故障的处理方法、装置、设备、介质和程序产品 - Google Patents

节点故障的处理方法、装置、设备、介质和程序产品 Download PDF

Info

Publication number
CN114942859A
CN114942859A CN202210690105.9A CN202210690105A CN114942859A CN 114942859 A CN114942859 A CN 114942859A CN 202210690105 A CN202210690105 A CN 202210690105A CN 114942859 A CN114942859 A CN 114942859A
Authority
CN
China
Prior art keywords
node
current node
fault
current
log information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210690105.9A
Other languages
English (en)
Inventor
李春祝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuhan United Imaging Healthcare Co Ltd
Original Assignee
Wuhan United Imaging Healthcare Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wuhan United Imaging Healthcare Co Ltd filed Critical Wuhan United Imaging Healthcare Co Ltd
Priority to CN202210690105.9A priority Critical patent/CN114942859A/zh
Publication of CN114942859A publication Critical patent/CN114942859A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请涉及一种节点故障的处理方法、装置、设备、介质和程序产品。该处理方法通过获取计算集群中当前节点上至少一种类型的日志信息；根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。本申请提供的节点故障的处理方法可以对节点本身存在的各种故障进行探测，能够保证Kubernetes***的正常运行。

Description

节点故障的处理方法、装置、设备、介质和程序产品
技术领域
本申请涉及集群技术领域，特别是涉及一种节点故障的处理方法、装置、设备、介质和程序产品。
背景技术
容器集群管理(Kubernetes)***是云原生领域的标准的开源容器编排和调度平台。Kubernetes***具有管理和维护集群中容器的能力，几乎可以提高服务零停机时间的保障。Kubernetes***由多个节点组成，且各节点上通过运行Pod执行各种计算任务。
目前的Kubernetes***在运行过程中，可以对各节点上的Pod进行监测，且在Pod发生故障时进行修复。具体的，在Pod或Pod中封装的容器出现故障时，Kubernetes***应用内置的活性探针和就绪探针来管理和控制应用程序的运行状况，让Kubernetes***对应的Pod或Pod中封装的容器实现"自愈"。
然而，Kubernetes***对Pod自身的修复能力都是建立在节点正常的情况下，但是对于节点本身存在的各种故障(硬件问题、内核死锁及文件***损坏、运行时挂住等)无法进行探测，从而导致Kubernetes***运行紊乱。
发明内容
基于此，有必要针对上述技术问题，提供一种节点故障的处理方法、装置、设备、介质和程序产品。
第一方面，本申请一个实施例提供一种节点故障的处理方法，该处理方法包括：
获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息；
根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在其中一个实施例中，该处理方法还包括：
根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
在其中一个实施例中，处理方法还包括：
对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
在其中一个实施例中，处理方法还包括：
若接收到计算集群中管理节点发送的节点释放命令，则切断当前节点与计算集群中各节点的连接关系。
在其中一个实施例中，处理方法还包括：
对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令，则重新建立当前节点与计算集群中各节点的连接关系。
在其中一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
第二方面，本申请一个实施例提供一种节点故障的处理装置，该处理装置包括：
获取模块，用于获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息；
确定模块，用于根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
第三方面，本申请一个实施例提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现如上述第一方面提供的处理方法的步骤。
第四方面，本申请一个实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面提供的处理方法的步骤。
第五方面，本申请一个实施例还提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如上述第一方面提供的处理方法的步骤。
本申请实施例提供一种节点故障的处理方法、装置、设备、介质和程序产品。该处理方法通过获取计算集群中当前节点上至少一种类型的日志信息；根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。在本实施例中，通过计算集群中各节点的日志信息可以对各节点本身存在的各种故障进行探测，能够确定发生故障的节点，从而使得工作人员可以及时对发生故障的节点进行修复。并且，在本实施例中，通过将发生故障的节点上运行的所有容器集成单元释放掉，能够避免发生故障的节点上的容器无法运行，导致Kubernetes***运行紊乱。
附图说明
为了更清楚地说明本申请实施例或传统技术中的技术方案，下面将对实施例或传统技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域不同技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为一个实施例提供的节点故障的处理方法的步骤流程示意图；
图2为一个实施例提供的节点问题检测器的工作模式示意图；
图3为另一个实施例提供的节点故障的处理方法的步骤流程示意图；
图4为一个实施例提供的Kubernetes***的结构示意图；
图5为一个实施例提供的监控Kubernetes***的流程示意图；
图6为一个实施例提供的节点故障的处理装置的结构示意图；
图7为本申请一个实施例提供的计算机设备的结构示意图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请的具体实施方式做详细的说明。在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似改进，因此本申请不受下面公开的具体实施例的限制。
首先，在具体介绍本公开实施例的技术方案之前，先对本公开实施例基于的技术背景或者技术演进脉络进行介绍。容器集群管理(Kubernetes)***是云原生领域的标准的开源容器编排和调度平台。Kubernetes***具有管理和维护集群中容器的能力，几乎可以提高服务零停机时间的保障。Kubernetes***包括一个管理节点和多个工作节点，管理节点用于向各工作节点上调度需要运行的Pod，各工作节点上通过运行Pod执行各种计算任务。在创建一个Pod资源后，Kubernetes***中的管理节点会为其选择工作节点，然后将其调度到该工作节点上运行Pod里的容器。
目前，Kubernetes***在运行过程中，可以对各工作节点上的Pod或容器进行监测，且在Pod或容器发生故障时进行修复。Kubernetes自身的***修复能力主要包括两方面：
第一方面，依托Pod的重启策略，重启策略也叫restartPolicy。它是Pod的Spec部分的一个标准字段(pod.spec.restartPolicy)，默认值是Always，即：任何时候这个容器停止，它一定会自动重启，可以通过设置restartPolicy，改变Pod的恢复策略。除了Always，restartPolicy还有OnFailure(容器非正常停止会自动重启，正常停止不会重启)和Never(容器不论以任何方式停止，都不会自动重启)两个值。
第二方面，使用两种健康检查实现自我修复策略，将Pod调度到某个工作节点后，该工作节点上的Kubelet组件将运行其中的容器，并在Pod的生命周期内保持它们的运行。如果容器的主进程崩溃，kubelet组件将重新启动容器。但是，如果容器内的应用程序抛出错误导致其不断重启，则Kubernetes***可以通过使用正确的诊断程序并遵循Pod的重启策略来对其进行修复。
其中，两种健康检查包括：
活性检查(Liveness)：kubelet使用活性探针(livenessProbe)的返回状态作为重新启动容器的依据。一个活性探针用于在应用运行时检测容器的问题。容器进入此状态后，Pod所在节点的kubelet组件可以通过Pod策略来重启容器。
就绪检查(Readiness)：这种类型的探针(readinessProbe)用于检测容器是否准备好接受流量。可以使用这种探针来管理哪些Pod会被用作服务的后端。如果Pod尚未准备就绪，则将其从服务的后端列表中删除。
上述两种健康检查使用相同类型的探针处理程序，对于未通过检查的Pod做出的纠错措施会有所不同。livenessProbe将重新启动容器，预期重启后错误不再发生；readinessProbe会将Pod与流量隔离，直到故障原因消失。
然而，上述的Kubernetes自身的***修复能力都是建立在工作节点正常，管理节点和工作节点之间能够进行正常通信的前提下，对于工作节点本身的各种问题，例如：硬件问题、内核死锁及文件***损害、运行时挂住等，无法被Kubernetes***内的组件探测，更不会修复。但是工作节点本身发生的各种问题会影响Pod的正常创建和服务，并且，Kubernetes***的控制平面(管理节点)对工作节点发生的各种问题一无所知，会继续将Pod调度到发生问题的工作节点上，从而引起新老Pod接二连三地失败造成访问故障，进而导致Kubernetes***运行紊乱。
下面以具体的实施例对本申请的技术方案以及本申请的技术方案如何解决技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
在一个实施例中，如图1所示，提供了一种节点故障的处理方法，本实施例以该方法应用于终端进行举例说明，该终端安装有Kubernetes***。终端可以但限于是各种个人计算机、笔记本电脑、物联网设备等。可以理解的是，该方法也可以应用于安装有Kubernetes***的服务器，服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。本实施例中，该方法包括以下步骤：
步骤100、获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息。
计算集群是指终端安装的Kubernetes***管理的集群，该集群中包括有多个工作节点。在每个工作节点上部署有节点问题检测器，多个问题守护线程以协程的形式运行在每个工作节点中。在终端中的Kubernetes***运行过程中，节点问题检测器通过执行特定的脚本运行多个问题守护线程获取当前节点的日志信息。不同问题守护线程对应不同的日志信息。具体地，多个问题守护线程包括内核问题守护线程、磁盘守护线程、文件夹守护线程以及用户自定义的可以监视节点其他问题的守护线程。通过内核问题守护线程可以获取当前节点的内核的状态，即内核的日志信息；通过磁盘守护线程可以获取当前节点的磁盘的状态，即磁盘的日志信息；通过文件夹守护线程可以获取当前节点的文件夹的状态，即文件夹的日志信息。
终端通过不同的问题守护线程获取计算集群中当前节点上至少一种类型的日志信息。不同类型的日志信息对应不同的问题守护线程。在本实施例中，对获取的具体的日志信息不作限制，工作人员可以根据自身需求选择执行不同的问题守护线程，获取不同的日志信息。
在一个具体的实施例中，节点问题检测器的工作模式如图2所示，节点文件检测器与多个不同的监视器连接，不同的监视器中运行有不同的问题守护线程，通过不同的监视器可以获取不同类型的日志信息。
步骤110、根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在当前节点发生故障时，日志信息中包括可以表征当前节点发生故障的信息。则终端在获取到至少一种类型的日志信息后，根据该日志信息能够确定当前节点是否为故障节点。本实施例对根据日志信息确定当前节点为故障节点的具体方法不作限制，只要能够实现其功能即可。
在一个实施例中，涉及根据获取的日志信息确定当前节点是否为故障节点的实现方式如图3所示，步骤包括：
步骤300、将日志信息与预设故障信息进行匹配，得到匹配结果。
预设故障信息包括每个日志信息对应的子故障信息。预设故障信息可以由工作人员预设存储在终端的存储器中。终端在获取日志信息后，将该日志信息与预设故障信息进行匹配，可以得到匹配结果。具体地，在终端获取到的日志信息包括多个时，终端可以将每个日志信息与预设故障信息中的多个子故障信息一一匹配，得到匹配结果；终端还可以先根据每个日志信息确定每个日志信息对应的子故障信息，再分别将每个日志信息与对应的子故障信息进行匹配，得到匹配结果。本实施例对具体的匹配过程不作限制，只要能够实现其功能即可。
步骤210、根据匹配结果确定当前节点是否为故障节点。
终端在获取匹配结果后，若确定匹配结果为匹配，即预设故障信息中存在与日志信相匹配的故障信息，表示当前节点发生故障，则将当前节点确定为故障节点。若终端确定匹配结果为不匹配，即预设故障信息中不存在与日志信息相匹配的故障信息，表示当前节点未发生故障。
终端在确定当前节点为故障节点后，释放当前节点上的所有容器集成单元。容器集成单元为Pod，容器集成单元中包括多个容器。也就是说，终端在当前节点为故障节点时，会将当前节点上运行的所有容器从当前节点移除。具体地，终端可以先将当前节点上运行的所有容器停止运行，再将停止运行后的所有容器从当前节点移除。终端也可以直接将在当前节点上运行的所有容器从当前节点移除。本实施例对从当前节点释放的所有容器集成单元的处理方法不作限制。
在一个可选的实施例中，Kubernetes***包括Draino(驱赶)组件，在确定当前节点为故障节点时，使用该组件可以驱赶当前节点上的所有容器集成单元(Pod)。具体地，在Draino组件中配置有驱赶当前节点上的Pod的缓冲时间，即确定当前节点为故障节点时，配置的缓冲时间内将当前节点上的Pod驱赶。
本申请实施例提供的节点故障处理方法通过获取计算集群中当前节点上至少一种类型的日志信息；根据该日志信息确定当前节点是否为故障节点，并在该当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。在本实施例中，通过计算集群中各节点的日志信息可以对各节点本身存在的各种故障进行探测，能够确定发生故障的节点，从而使得工作人员可以及时对发生故障的节点进行修复。并且，本实施例中，通过将发生故障的节点上运行的所有容器集成单元(Pod)释放掉，能够避免发生故障的节点上的容器无法运行，导致Kubernetes***运行紊乱。
在一个实施例中，终端在释放当前节点上的所有容器集成单元之后，对释放的所有容器集成单元的处理方法包括：
根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
由于Kubernetes***中的集群是动态的，并且其状态会随着时间的变化而变化，可能需要将已经运行的Pod迁移到其他节点上，则设置了预设调度策略。若出现节点利用率不足或者过度使用、节点发生故障和添加新的节点到集群中的任意一种或多种情况时，可以使用预设的调度策略将该节点上运行的Pod进行迁移处理。预设调度策略中可以包括多种调度策略，对于节点出现的不同情况，可以使用不同的调度策略。本实施例对预设调度策略的具体内容不作限制，工作人员可以根据实际应用环境自行设置。
终端在确定故障节点，并将该故障节点上运行的容器集成单元释放后，根据预设调度策略，能够将释放的所有容器集成单元迁移至其他节点，即，将故障节点上运行的容器迁移至其他节点上，使其可以继续运行。
在本实施例中，在将故障节点上的所有容器集成单元释放后，根据预设调度策略将释放的所有容器集成单元迁移至其他节点上，使得故障节点上运行的所有容器集成单元在其他节点上还可以正常运行，从而能够保证Kubernetes***可以正常运行。
在一个可选的实施例中，Kubernetes***包括Descheduler(去调度器)，在确定当前节点为故障节点时，使用Descheduler可以将当前节点上的所有容器集成单元迁移至其他节点。
在一个实施例中，在确定当前节点为故障节点后，节点故障的处理方法的步骤还包括：
对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
终端在确定当前节点为故障节点后，对当前节点添加污点标签，通过该污点标签可以使得该当前节点不再接收其他容器集成单元。也就是说，在当前节点上设置有污点标签时，在有新的容器集成单元调度至当前节点时，当前节点会拒绝新的容器集成单元。
在本实施例中，通过在发生故障的当前节点上添加污点标签，可以避免新的容器集成单元调度至该当前节点上无法运行，导致应用层访问异常，从而能够保证Kubernetes***正常运行。
在一个可选的实施例中，终端的Kubernetes***启用了
TaintNodesByCondition(终止问题节点)功能，在当前节点发生故障时，当前节点会被添加Effect(效果)为NoSchedule(不调度)的taints(污点)，该污点可以是一个条件，Kubernetes***中的Descheduler会将不满足此taints的Pod，即当前节点不接收不满足此taints的Pod。
在一个实施例中，节点故障的处理方法还包括：
若接收到计算集群中管理节点发送的节点释放命令时，则切断当前节点与计算集群中各节点的连接关系。
终端在接收到部署在当前节点的节点问题检测器发送的当前节点的故障消息后，能够确定当前节点发生故障。节点问题检测器同时会向终端的Kubernetes***中的管理节点发送消息，以告知管理节点当前节点发生故障，管理节点会发送节点释放命令，即需要将发生故障的当前节点从该计算集群中移除。若当前节点接收到管理节点发送的节点释放命令，当前节点响应于节点释放命令，会切断与计算集群中其他节点之间的连接关系，以达到将当前节点移除计算集群的目的。
在本实施例中，通过切断当前节点与计算集群中其他节点之间的连接关系，能够将当前节点从计算集群中移除，从而能够终止发生故障的当前节点的工作，也不会有新的Pod调度至当前节点上。
在一个实施例中，在Kubernetes***中配置有集群自动缩放器，在发生故障的当前节点上的Pod被释放后，该当前节点的资源未得到充分利用，此时，集群自动缩放器会将当前节点从计算集群中移除。具体地，集群自动缩放器可以与Draino组件一起使用，即在使用Draino组件将发生故障的当前节点上的Pod释放后，集群自动缩放器会将该当前节点从计算集群中移除。集群自动缩放器也可以与Descheduler一起使用，即在使用Descheduler将发生故障的当前节点上的Pod迁移到集群的其他节点后，集群自动缩放器会将该当前节点从计算集群中移除。
在一个实施例中，终端在将发生故障的当前节点从计算集群中移除后，节点故障的处理方法还包括：
对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令，则重新建立当前节点与计算集群中各节点的连接关系。
终端在确定从计算集群中移除后的当前节点后，会对当前节点进行故障修复。具体的修复方法与当前节点发生的具体故障相对应，本实施例对具体的故障修复方法不作限制，只要能够实现其功能即可。
在发生故障的当前节点的故障被修复，可以正常工作时，当前节点上部署的节点问题检测器，能够检测到该当前节点可以正常工作，则节点问题检测器会向Kubernetes***中的管理节点发送消息，告知该当前节点已被修复，管理节点会向修复后的当前节点发送节点加入命令。若修复后的当前节点会接收到节点加入命令，则响应于该命令重新建立与计算集群中其他节点之间的连接关系，以达到当前节点重新接入计算集群的目的。
在本实施例中，在对发生故障的当前节点的故障修复后，能够将修复后的当前节点重新加入的计算集群中，可以分担计算集群中其他节点上运行的Pod，能够避免计算集群中其他节点出现过度使用等现象，从而能够保证Kubernetes***的正常运行。
在一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
守护进程是指保证Kubernetes***与外部的终端或服务器正常通信的进程。在一个可选的实施例中，在当前节点发生故障时，终端可以先对当前节点所在***的内核参数以及守护进程参数进行重新配置。若对参数进行重新配置后实现了对当前节点的故障的修复，然后执行将当前节点重新加入计算集群中的步骤；若对参数进行重新配置后未对当前节点的故障进行修复，则对守护进程进行重启。若对守护进程进行重启后实现了对当前节点的故障的修复，然后执行将当前节点重新加入计算集群中的步骤；若对守护进程进行重启后未对当前节点的故障进行修复，则对当前节点进行重启。若对当前节点进行重启后实现了对当前节点的故障的修复，然后执行将当前节点重新加入计算集群中的步骤；若对当前节点进行重启后未对当前节点的故障进行修复，则对当前节点的***进行重新安装。
在另一个可选的实施例中，当前节点发生的故障不同，进行故障修复的方法也不同。若当前节点的内核发生故障，则能够通过对当前节点所在***的内核参数以及守护进行参数进行重新配置，或者对守护进程进行重启实现对故障的修复。若当前节点的文件***发生故障，则能够对当前阶段进行重启，或者对当前节点的***进行重新安装。若当前节点发生硬件问题，则需要工作人员对当前节点进行替换。
在一个实施例中，节点故障的处理方法还包括：
获取发生故障的当前节点的故障信息，对故障信息进行存储并向计算集群的管理设备发送警示信息。
当前节点的故障信息包括发生故障的当前节点的日志信息，终端对故障信息进行存储，便于后续对其进行分析。同时，终端会向计算集群的管理设备发送警示信息，以便于管理设备可以及时对发生故障的节点进行相对应的修复操作。警示信息可以包括警示铃。计算集群的管理设备可以是监视***(Prometheus)。
在一个实施例中，在将节点移除计算集群之前，按照预设的策略对节点进行移除和修复。
为了防止计算集群中的节点雪崩，在将节点移除计算集群时，对节点进行修复之前做严格的限流，防止节点大规模重启。具体地的限流方法可以包括：在同一时刻只允许计算集群中的特定数量的节点(例如一个节点)进行移除和修复；或者进行移除和修复的各节点之间的时间间隔至少预设时间(例如1分钟)；或者同一时刻允许进行移除和修复的各节点之间的时间间隔至少预设时间。
在一个实施例中，在将修复好的当前节点加入计算集群时，给当前节点特定的容忍时间。也就是说，在将修复好的当前节点加入计算集群时，会在容忍时间(例如2分钟)后再向该当前节点调度容器集成单元。这样能够防止由于当前节点刚刚添加到计算集群中的不稳定性导致对当前节点是否存在故障进行误判。
在一个实施例中，如图4所示，Kubernetes***还包括自动修复控制器，Kubernetes***中的节点问题检测器会根据获取到的日志信息确定发生故障的节点，并通过接入服务器将发生故障的节点对应的日志信息发送至自动修复控制器，自动修复控制器会根据接收到的日志信息对发生故障的节点进行相应的修复操作。
在一个实施例中，对Kubernetes***中计算集群的各节点的监控流程如图5所示。通过节点问题检测器获取Kubernetes***中计算集群的节点的日志信息，并根据该日志信息确定发生故障的节点，并将发生故障的节点对应的日志信息发送至数据库和用户终端。发送至数据库中的日志信息可以直接可视化显示，也可以通过各种算法对该日志信息进行分析处理。发送至用户终端的日志信息可以提示用户Kubernetes***中计算集群中存在发生故障的节点。节点问题检测器还会将发生故障节点对应的日志信息发送至监控***(Prometheus)，该监控***将接收到的信息发送至用户终端。
对发生故障的节点的修复可以是节点问题检测器将发生故障的节点对应的日志信息发送至自动修复控制器，自动修复控制器根据该日志信息对发生故障的节点进行修复。
应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的节点故障的处理方法的节点故障的处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个节点故障的处理装置实施例中的具体限定可以参见上文中对于节点故障的处理方法的限定，在此不再赘述。
在一个实施例中，如图6所示，提供了一种节点故障的处理装置10，包括获取模块11和确定模块12。其中，
获取模块11用于获取计算集群中当前节点上至少一种类型的日志信息；所日志信息包括当前节点的工作状态信息；
确定模块12用于根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在一个实施例中，节点故障的处理装置10还包括迁移模块。迁移模块用于根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
在一个实施例中，节点故障的处理装置10还包括设置模块。设置模块用于对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
在一个实施例中，节点故障的处理装置10还包括切断模块。切断模块用于若接收到计算集群中管理节点发送的节点释放命令时，则切断当前节点与计算集群中各节点的连接关系。
在一个实施例中，节点故障的处理装置10还包括修复模块。修复模块用于对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令时，则重新建立当前节点与计算集群中各节点的连接关系。
在一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
上述节点故障的处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图7所示。该计算机设备包括通过***总线连接的处理器、存储器、通信接口和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***和计算机程序。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种节点故障的处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，处理器执行计算机程序时实现以下步骤：
获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息；
根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：若接收到计算集群中管理节点发送的节点释放命令时，则切断当前节点与计算集群中各节点的连接关系。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令时，则重新建立当前节点与计算集群中各节点的连接关系。
在一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息；
根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：若接收到计算集群中管理节点发送的节点释放命令时，则切断当前节点与计算集群中各节点的连接关系。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令时，则重新建立当前节点与计算集群中各节点的连接关系。
在一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
获取计算集群中当前节点上至少一种类型的日志信息；日志信息包括当前节点的工作状态信息；
根据日志信息确定当前节点是否为故障节点，并在当前节点为故障节点的情况下，释放当前节点上的所有容器集成单元。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：对当前节点进行污点标签设置；污点标签用于指示当前节点停止接收其他容器集成单元。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：若接收到计算集群中管理节点发送的节点释放命令时，则切断当前节点与计算集群中各节点的连接关系。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：对当前节点进行故障修复，若接收到计算集群中管理节点发送的节点加入命令时，则重新建立当前节点与计算集群中各节点的连接关系。
在一个实施例中，对当前节点进行故障修复的方法包括：对当前节点所在***的内核参数以及守护进程参数进行重新配置、对守护进程进行重启、对当前节点进行重启、对当前节点的***进行重新安装中的至少一种。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种节点故障的处理方法，其特征在于，所述处理方法包括：
获取计算集群中当前节点上至少一种类型的日志信息；所述日志信息包括所述当前节点的工作状态信息；
根据所述日志信息确定所述当前节点是否为故障节点，并在所述当前节点为故障节点的情况下，释放所述当前节点上的所有容器集成单元。
2.根据权利要求1所述的处理方法，其特征在于，所述处理方法还包括：
根据预设调度策略，将释放的所有容器集成单元迁移至其他节点。
3.根据权利要求1所述的处理方法，其特征在于，所述处理方法还包括：
对所述当前节点进行污点标签设置；所述污点标签用于指示所述当前节点停止接收其他容器集成单元。
4.根据权利要求1-2任一项所述的处理方法，其特征在于，所述处理方法还包括：
若接收到所述计算集群中管理节点发送的节点释放命令，则切断所述当前节点与所述计算集群中各节点的连接关系。
5.根据权利要求1-2任一项所述的处理方法，其特征在于，所述处理方法还包括：
对所述当前节点进行故障修复，若接收到所述计算集群中管理节点发送的节点加入命令，则重新建立所述当前节点与所述计算集群中各节点的连接关系。
6.根据权利要求1所述的处理方法，其特征在于，对所述当前节点进行故障修复的方法包括：对所述当前节点所在***的内核参数以及守护进程参数进行重新配置、对所述守护进程进行重启、对所述当前节点进行重启、对所述当前节点的***进行重新安装中的至少一种。
7.一种节点故障的处理装置，其特征在于，所述处理装置包括：
获取模块，用于获取计算集群中当前节点上至少一种类型的日志信息；所述日志信息包括所述当前节点的工作状态信息；
确定模块，用于根据所述日志信息确定所述当前节点是否为故障节点，并在所述当前节点为故障节点的情况下，释放所述当前节点上的所有容器集成单元。
8.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的处理方法的步骤。
9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的处理方法的步骤。
10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的处理方法的步骤。
CN202210690105.9A 2022-06-17 2022-06-17 节点故障的处理方法、装置、设备、介质和程序产品 Pending CN114942859A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210690105.9A CN114942859A (zh) 2022-06-17 2022-06-17 节点故障的处理方法、装置、设备、介质和程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210690105.9A CN114942859A (zh) 2022-06-17 2022-06-17 节点故障的处理方法、装置、设备、介质和程序产品

Publications (1)

Publication Number Publication Date
CN114942859A true CN114942859A (zh) 2022-08-26

Family

ID=82910971

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210690105.9A Pending CN114942859A (zh) 2022-06-17 2022-06-17 节点故障的处理方法、装置、设备、介质和程序产品

Country Status (1)

Country Link
CN (1) CN114942859A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115733734A (zh) * 2022-10-11 2023-03-03 北京市建筑设计研究院有限公司 一种服务节点的修复方法、装置、电子设备及存储介质
CN116155686A (zh) * 2023-01-30 2023-05-23 浪潮云信息技术股份公司 一种云环境下判定节点故障的方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115733734A (zh) * 2022-10-11 2023-03-03 北京市建筑设计研究院有限公司 一种服务节点的修复方法、装置、电子设备及存储介质
CN116155686A (zh) * 2023-01-30 2023-05-23 浪潮云信息技术股份公司 一种云环境下判定节点故障的方法
CN116155686B (zh) * 2023-01-30 2024-05-31 浪潮云信息技术股份公司 一种云环境下判定节点故障的方法

Similar Documents

Publication Publication Date Title
US10152382B2 (en) Method and system for monitoring virtual machine cluster
US11321197B2 (en) File service auto-remediation in storage systems
US8954579B2 (en) Transaction-level health monitoring of online services
US8156490B2 (en) Dynamic migration of virtual machine computer programs upon satisfaction of conditions
US8910172B2 (en) Application resource switchover systems and methods
US9712418B2 (en) Automated network control
US8990388B2 (en) Identification of critical web services and their dynamic optimal relocation
US9483314B2 (en) Systems and methods for fault tolerant batch processing in a virtual environment
CN114942859A (zh) 节点故障的处理方法、装置、设备、介质和程序产品
US9495234B1 (en) Detecting anomalous behavior by determining correlations
US9535754B1 (en) Dynamic provisioning of computing resources
US11157373B2 (en) Prioritized transfer of failure event log data
US7673178B2 (en) Break and optional hold on failure
US9195528B1 (en) Systems and methods for managing failover clusters
CN115562911A (zh) 虚拟机数据备份方法及装置、***、电子设备、存储介质
CN111538585A (zh) 一种基于node.js的服务器进程调度方法、***和装置
US11544091B2 (en) Determining and implementing recovery actions for containers to recover the containers from failures
US9274905B1 (en) Configuration tests for computer system
CN114691304A (zh) 实现集群虚拟机高可用的方法和装置、设备和介质
CN112256384B (zh) 基于容器技术的服务集合处理方法、装置和计算机设备
JP2018169920A (ja) 管理装置、管理方法及び管理プログラム
JP2012181737A (ja) 計算機システム
US11323315B1 (en) Automated host management service
CN107783855B (zh) 虚拟网元的故障自愈控制装置及方法
WO2023185355A1 (zh) 实现集群虚拟机高可用的方法和装置、设备和介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination