CN111752759A

CN111752759A - Kafka集群故障恢复方法、装置、设备及介质

Info

Publication number: CN111752759A
Application number: CN202010620536.9A
Authority: CN
Inventors: 王伟松
Original assignee: Chongqing Unisinsight Technology Co Ltd
Current assignee: Chongqing Unisinsight Technology Co Ltd
Priority date: 2020-06-30
Filing date: 2020-06-30
Publication date: 2020-10-09
Anticipated expiration: 2040-06-30
Also published as: CN111752759B

Abstract

本申请提供一种Kafka集群故障恢复方法、装置、设备及介质，该方法包括：根据预设的配置文件利用Kubernetes平台创建备份的本地存储卷；获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及Kafka Pod所使用的PVC；检测每个Kafka Pod所属节点和Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；解除状态异常的Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系；将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷。在Kubernetes平台内设置自动检测Kafka集群故障和自动恢复Kafka集群故障的机制，一方面，提升了Kafka集群使用LocalPV存储系统可靠性和稳定性；另一方面，也提高了维护效率，节省了维护成本。

Description

Kafka集群故障恢复方法、装置、设备及介质

技术领域

本申请涉及计算机领域，特别是涉及一种基于Kubernetes平台LocalPV的Kafka集群故障恢复方法、装置、设备及介质。

背景技术

Kafka是由Apache软件基金会开发的一个开源消息处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布/订阅消息系统，能够支撑海量数据的数据传递。Kafka将信息持久化到磁盘中，其优良的性能和数据稳定性，使Kafka得到了广泛的使用。Kubernetes平台是用于自动部署、扩展和管理容器化应用程序的开源系统。以Pod的形式运行在Kubernetes平台中的Kafka集群，其数据持久化在LocalPV中。LocalPV(LocalPersistent Volume)即本地存储卷，是Kubernetes平台的组件，其本质是使用节点的本地存储。相比于共享存储提升数据存储的性能，使用LocalPV意味着一旦节点或者磁盘发生异常，使用该LocalPV的Kafka Pod也会异常。Kafka Pod异常必然影响Kafka集群的可用性、集群的性能以及降低集群的可靠性，甚至会出现数据丢失的严重后果。因此，亟需一种基于Kubernetes平台针对localPV异常的自动恢复机制来解决上述问题。

发明内容

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种Kafka集群故障恢复方法、装置、设备及介质，用于解决现有技术中Kubernetes平台内LocalPV异常导致Kafka集群问题。

为实现上述目的及其他相关目的，本申请提供一种Kafka集群故障恢复方法，包括：

根据预设的配置文件利用Kubernetes平台创建备份的本地存储卷；

获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述Kafka Pod所使用的PVC；

检测每个所述Kafka Pod所属节点和所述Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；

解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系；

将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷用以恢复Kafka集群故障。

在本申请的另一目的在于提供一种Kafka集群故障恢复装置，包括：

辅助模块，用于根据预设的配置文件利用Kubernetes平台创建备份的本地存储卷；

查询模块，用于获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述Kafka Pod所使用的PVC；

检测模块，用于检测每个所述Kafka Pod所属节点和所述Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；

控制模块，用于解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系；

数据恢复模块，用于将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷用以恢复Kafka集群故障。

在本申请的另一目的在于提供一种电子设备，包括：

一个或多个处理装置；

存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置执行所述Kafka集群故障恢复方法。

在本申请的还一目的在于提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序用于使所述计算机执行所述Kafka集群故障恢复方法。

如上所述，本申请的Kafka集群故障恢复方法、装置、设备及介质，具有以下有益效果：

本申请在Kubernetes平台内设置自动检测Kafka集群故障和自动恢复Kafka集群故障的机制，一方面，提升了Kafka集群使用LocalPV存储系统可靠性和稳定性；另一方面，也提高了维护效率，节省了维护成本。

附图说明

图1显示为本申请提供的一种Kafka集群故障恢复方法流程图；

图2显示为本申请提供的一种Kafka集群故障恢复方法另一流程图；

图3显示为本申请提供的一种Kafka集群故障恢复方法完整流程图；

图4显示为本申请提供的一种Kafka集群故障恢复原理框架图；

图5显示为本申请提供的一种Kafka集群故障恢复装置结构框图；

图6显示为本申请一实施例提供的一种Kafka集群正常状态图；

图7显示为本申请一实施例提供的一种Kafka集群节点故障状态图；

图8显示本申请一实施例提供的一种Kafka集群节点恢复后的状态图；

图9显示为本申请另一实施例提供的一种Kafka集群正常状态图；

图10显示为本申请另一实施例提供的一种Kafka集群localpv故障状态图；

图11显示本申请另一实施例提供的一种Kafka集群localpv恢复后的状态图；

图12显示为本申请一实施例提供的一种电子设备的结构示意图。

具体实施方式

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本申请的基本构想，遂图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

请参阅图1，为本申请提供的一种Kafka集群故障恢复方法流程图，包括：

步骤S1，根据预设的配置文件利用Kubernetes平台创建备份的本地存储卷(localpv)；

其中，对本地存储设备的空间进行计算、分区、格式化和挂载分区到配置目录，通过传入配置文件，输出挂载到配置目录下实现分区，辅助Kubernetes平台创建LocalPV(本地存储卷)，例如：sgdisk(分区工具)、fdisk(硬盘分区)、mount(命令工具)等。

步骤S2，获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述Kafka Pod所使用的PVC；

其中，通过抓取目标和关键词输出抓取信息，具体地实施工具包括但不限于kubectl(命令行工具)、docker(引擎)，API客户端库和python客户端库等。

步骤S3，检测每个所述Kafka Pod所属节点和所述Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；

其中，对传入的节点和localpv进行故障检测，生成故障检测结果，其中，通过状态异常的节点也能够查询到节点内的本地存储卷，即，最终检测结果都能以本地存储卷进行显示。检测的具体实施方式包括但不限于Kubernetes节点状态检查，存储设备读写功能检测、网络功能检测、Pod状态检查等。

需要说明的是，检测的结果可以是状态异常的节点，也可以是状态异常的本地存储卷，再或者是状态异常的节点和状态异常的本地存储卷。

步骤S4，解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系；

其中，通过解除(删除)状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，建立状态异常的所述Kafka Pod所使用的PVC和备份的本地存储卷之间的绑定关系，以便后续进行数据恢复。

步骤S5，将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷用以恢复Kafka集群故障。

其中，通过备份的本地存储卷同步状态异常的节点或/和状态异常的本地存储卷的数据，从而实现对状态异常的节点或/和状态异常的本地存储卷进行数据恢复。

在本实施例中，在Kubernetes平台内设置自动检测Kafka集群故障和自动恢复Kafka集群故障的机制，一方面，提升了Kafka集群使用LocalPV存储的系统可靠性和稳定性；另一方面，也提高了维护效率，节省了维护成本。

请参阅图2，为本申请提供的一种Kafka集群故障恢复方法另一流程图，在上述图1实施例基础上，在步骤S4之前，还包括：

步骤S31，根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬性需求。

在此，通过生成状态异常的检测结果后，核查备份的本地存储卷是否满足故障恢复的硬性需求。

需要说明的是，通过核查硬性需求，确保了所述状态异常的节点或/和状态异常的本地存储卷能够恢复数据，满足后续故障恢复的硬性需求，从而提高存储系统可靠性和稳定性。

在一些实施例中，由于步骤S31当检测到状态异常的节点需恢复故障时，核查的步骤进一步包括：

检查备份的本地存储卷的空间是否大于等于状态异常的节点上Kafka Pod所使用的PVC声明空间；如果备份的本地存储卷的空间大于等于状态异常的节点上Kafka Pod所使用的PVC声明空间，且该备份的本地存储卷所属节点与状态异常的节点不同，则将状态异常的节点上的Kafka Pod与所述Kafka Pod所使用的PVC标记为删除；否则，不标记。

通过上述方式，一方面，确定备份的本地存储卷的存储空间能够满足状态异常的节点所对应PVC声明空间，另一方面，精准确定备份的本地存储卷所属节点，通过将状态异常的节点上的Kafka Pod与所述Kafka Pod所使用的PVC标记为删除，有利于后续删除故障(状态异常的)节点，恢复特定故障数据。

在另一些实施例中，针对状态异常的节点所述步骤S4具体包括：根据Kafka集群状态删除状态异常节点的Kafka Pod和对应的PVC，利用新节点创建(已)删除的所述KafkaPod和对应的PVC，建立新节点内创建的PVC与备份的本地存储卷绑定关系。

通过上述方式，核查Kafka集群其余Kafka Pod的状态，利用Kafka集群状态删除状态异常节点的Kafka Pod和对应的PVC，重新建立备份的本地存储卷与新节点内的PVC的绑定关系，从而完整实现状态异常的节点的数据恢复。

在一些实施例中，针对于备份的本地存储卷与状态异常的本地存储卷是否属于同一节点对后续标记删除的PVC有很大差异，因此，采用步骤S31检测到状态异常的本地存储卷恢复故障时，核查的步骤进一步包括：

检查备份的本地存储卷的空间是否大于等于状态异常的本地存储卷对应PVC声明空间；

如果备份的本地存储卷的空间大于等于状态异常的本地存储卷对应PVC声明空间，且备份的本地存储卷与状态异常的本地存储卷属于同一节点，则将状态异常的本地存储卷与其关联的PVC标记为删除；否则，不标记；

如果备份的本地存储卷的空间大于等于状态异常的本地存储卷对应PVC声明空间，且备份的本地存储卷与状态异常的本地存储卷属于不同节点，则将状态异常的本地存储卷所属节点上Kafka Pod和所述Kafka Pod使用的PVC和状态异常的本地存储卷标记为删除；否则，不标记。

在本实施例中，一方面，确定备份的本地存储卷的存储空间能够满足状态异常的本地存储卷所对应PVC声明空间，另一方面，精准确定备份的本地存储卷所属节点，通过将状态异常的本地存储卷和关联的PVC标记为删除，有利于后续删除故障(状态异常的)本地存储卷，恢复特定故障数据。

在另一些实施例中，针对状态异常的本地存储卷所述步骤S4具体包括：

根据Kafka集群状态当备份的本地存储卷与状态异常的本地存储卷属于同一节点时，删除状态异常的本地存储卷以及其关联PVC的绑定关系，利用备份的本地存储卷与该PVC建立绑定关系；

根据Kafka集群状态当备份的本地存储卷与状态异常的本地存储卷属于不同节点时，删除状态异常的本地存储卷所属节点上Kafka Pod和所述Kafka Pod使用的PVC和状态异常的本地存储卷，在备份的本地存储卷所属节点内重新创建所述Kafka Pod和PVC，并利用备份的本地存储卷与创建的PVC建立绑定关系。

通过上述方式，核查Kafka集群以及其余Kafka Pod的状态，利用Kafka集群状态删除状态异常本地存储卷和对应的PVC，重新建立备份的本地存储卷与PVC的绑定关系，从而实现状态异常的本地存储卷的数据恢复。

在上述实施例上，当同时检测到状态异常的节点和状态异常的本地存储卷时，结合上述实施方式即可，在此不一一赘述。

实施例1

请参阅图4，为本申请提供的一种Kafka集群故障恢复原理框架图，基于Kubernetes平台LocalPV的Kafka集群故障恢复装置，该装置由LocalPV辅助模块(LocalPVHelper Module,LPHM)、Kafka Pod查询模块(Kafka Pod Query Module，KPQM)、Kafka Pod控制模块(Kafka Pod Control Module,KPCM)、Kafka Pod检测模块(Kafka Pod DetectionModule,KPDM)和Kafka数据恢复模块(Kafka Data Recovery Module，KDRM)构成，各个模块之间互相协作实现基于Kubernetes平台LocalPV的Kafka集群自动故障恢复。请参阅图3，为本申请提供的一种Kafka集群故障恢复方法完整流程图，该故障恢复步骤如下：

A、导入配置文件，并分别启动LPHM、KPQM、KPCM、KPDM和KDRM模块；

B、LPHM模块根据步骤A中的配置文件对本地存储进行分区、格式化和挂载分区到配置目录下等操作，Kubernetes的localPV组件根据配置的挂载目录下的分区预创建至少1个但不限于1个备份LocalPV；

C、KPQM获取Kubernetes集群中所有Kafka Pod的名称、所属节点、PVC(PersistentVolume Claim)等信息，并传入KPCM；

D、根据Kafka Pod的PVC信息，KPQM获取PVC绑定的LocalPV的名称、LocalPV对应本地存储的存储路径等信息，并传入KPCM；

E、KPCM将Kafka Pod所属节点以及Kafka pod使用的localPV信息导入KPDM模块，KPDM模块分别检测Kafka pod所属节点和localPV的健康状态，并导出不健康(状态异常)的节点和localPV信息到KPCM模块；

F、KPCM根据不健康(状态异常)节点信息查找部署在该节点的kafka pod的PVC信息，核查第二步(步骤B)创建的备份localPV的空间和所属节点信息，如果备份localPV中存在空间大于等于PVC声明的空间，并且不属于不健康节点，则标记该PVC删除和PVC对应的LocalPV不删除，否则标记该PVC和PVC对应的LocalPV均不删除；

G、KPCM根据不健康localPV信息查找到使用其的Kafka pod，获取该Kafka pod使用的全部PVC，对于其中与不健康LocalPV绑定的PVC核查第二步(步骤B)创建的备份localPV空间和所属节点信息，如果备份localPV中存在空间大于等于PVC声明的空间，并且备份localPV与故障LocalPV属于同一节点，则标记PVC和PVC绑定的localPV删除，否则，该Kafka pod的PVC和LocalPV全部标记不删除。如果备份localPV中分别存在空间大于等于PVC声明的空间，并且备份localPV与故障LocalPV不属于同一节点，则分别标记Kafka pod使用的PVC删除，不健康LocalPV删除，健康LocalPV不删除，否则该Kafka pod的PVC和LocalPV全部标记不删除；

H、KPCM核查Kafka集群状态，根据集群状态将标记为删除的PVC，KPCM向Kubernetes平台发送停止对应Kafka pod的请求，Kafka pod停止后发送删除PVC的请求，PVC删除成功，解除Kafka Pod PVC和LocalPV的绑定；

I、根据标记为删除的localPV，KPCM将localPV使用的本地存储从节点移除，移除成功后，向KUbernetes平台发送删除该LocalPV的请求，LocalPV删除成功。

J、KPCM向Kubernetes平台发送重启已停止的Kafka Pod请求，Kubernetes平台将重建PVC并绑定第二步骤中预创建的LocalPV，Kafka Pod开始正常运行；

K、KDRM设置kafka follow副本向leader同步数据的速度，并开始恢复J步骤中kafka Pod的数据，数据恢复完成，Kafka集群开始正常运行。

在一些示例中，LPHM负责对本地存储设备进行计算空间、分区、格式化和挂载分区到配置目录，使用方式为传入配置文件，输出挂载到配置目录下的分区，辅助Kubernetes平台创建LocalPV，工具包括但不限于sgdisk、fdisk、mount等。

在一些示例中，KPQM负责抓取目标和关键词，并输出抓取信息，具体的实现方式包括但不限于CLI工具如kubectl、docker，API客户端库如python客户端库等。

在一些示例中，KPCM负责接收输入信息和流程控制，根据输入信息控制整个故障恢复过程，并向Kubernetes平台发送执行动作的请求，具体的实现方式包括但不限于Kubernetes CLI工具如kubectl、docker，API客户端库如python客户端库等。

在一些示例中，KPDM负责对传入的节点和localPV进行故障检测，输出检测结果。检测具体的实现方式包括但不限于Kubernetes节点状态检查，存储设备读写功能检测、网络功能检测、Pod状态检查等。

在一些示例中，KDRM负责设置Kafka follower副本向leader副本同步数据的速度和恢复Kafka故障pod丢失的数据，具体的实现方式包括但不限于Kafka副本数据恢复，数据快照恢复等。

在一些示例中，所述步骤A中LPHM配置文件包括但不限于节点IP，节点名称，存储设备，存储设备类型，存储设备分区数目等。

在一些示例中，所述步骤C中Kafka Pod对应至少1个但不限于1个PVC。

在一些示例中，所述步骤D中Kafka pod的PVC与使用的localPV存在一对一绑定关系，通过PVC可以获取与其绑定的LocalPV信息。

在一些示例中，所述步骤E中不健康的节点包括但不限于离线节点，断电节点，操作系统故障节点等，检测的方法包括但不限于kubernetes平台获取节点状态，检查节点网络状态等，不健康的LocalPV包括但不限于存储设备读写故障，存储设备挂载故障等，检测方法包括但不限于获取存储设备状态信息，存储设备读写功能检测，挂载信息检测等。

在一些示例中，所述步骤F和G中，核查备份LocalPV的信息包括LocalPV的空间，所属节点等信息。

在一些示例中，所述步骤H中，核查Kafka集群状态包括故障Kafka pod的数量等。

在一些示例中，所述步骤J中，恢复的Kafka Pod数据是指分配到该Pod上的全部数据。

在一些示例中，上述步骤中LocalPV的底层存储设备可以是物理存储设备或虚拟存储设备。

实施例2

如图6所示，为本申请一实施例提供的一种Kafka集群正常状态图，表示kafka集群正常状态，黑色虚线框表示Kubernetes平台，Node-1，Node-2，Node-3，Node-4，Node-5是Kubernetes平台内的节点，黑色虚线框部署在Kubernetes平台内的Kafka集群，在Node-1部署KPQM、KPCM、KPDM和KDRM模块，在Node-2、Node3,、Node4上部署KPDM模块，在Node5上部署LPHM和KPDM模块，Kafka集群运行在Node2、Node3、Node4节点上。

如图7所示，为本申请一实施例提供的一种Kafka集群节点故障状态图，其中，Node4节点故障。如图8所示，为本申请一实施例提供的一种Kafka集群节点恢复后的状态图，即图7故障恢复后的状态图。

配置文件信息如下：

node:Node-5

disks:

-disk:/dev/sdc

partitions:2

class:ssd

mountdir:/mnt/local-disks/ssd

本实施例中，Kafka集群节点故障自动恢复的步骤如下：

A、通过在Node-5节点导入配置文件，分别启动LPHM、KPQM、KPCM、KPDM和KDRM；

B、LPHM读取配置文件中的信息，根据配置信息将Node-5节点上的/dev/sdc存储设备，平均分成2个分区并挂载到/mnt/local-disks/ssd的子目录下，Kubernetes平台组件将localpv-6、localpv-7安装成功；

C、KPQM获取图6中3个Kafka pod信息，包括名称、PVC、所属节点，例如，kafka-0，pvc-0、pvc-1，node-2，其它pod节点类似；

D、KPQM根据C步骤中的PVC信息，获取与其绑定的LocalPV信息，例如，pvc-0绑定的localpv-0，pvc-1绑定的localpv-1；并将信息传入KPCM

E、KPCM将获取的C、D两步骤的信息，分别导入图6中的各个KPDM模块，Node-1节点中的KPDM通过kubectl命令获取kubernetes平台的节点状态信息，Node-2、Node-3、Node-4节点中的KPDM通过dd命令测试本节点localpv读写功能，检测到Node-4节点处于不健康状态，进入图7所示状态，导出不健康的节点Node-4到KPCM模块；

F、KPCM根据不健康的节点Node-4可以查找到pvc-4、pvc-5，核查步骤B中创建的locapv-6、localpv-7空间大于等于pvc-4、pvc-5的声明空间，核查结果满足条件则标记该pvc-4、pvc-5删除以及localpv-4、localpv-5不删除；

G、核查Kafka除kafka-2pod均健康，KPCM则使用kubectl delete命令删除kafka-2pod和标记为删除的pvc-4、pvc-5

H、KPCM向Kubernetes平台发送重启kafka-2pod的请求，kafka-2pod将被调度到Node-5节点，重新创建pvc-4、pvc-5，并与Node-5节点的localpv-6、localpv-7绑定。

I、KDRM使用kafka自带的kafka-configs.sh脚本工具设置kafka follower副本向leader副本同步数据的速度，并依赖kafka自身的副本恢复机制恢复kafka-2pod的数据，数据恢复完成后，kafka集群正常运行，进入图8的状态。

实施例3

如图9所示，为本申请另一实施例提供的一种Kafka集群正常状态图，其中，黑色虚线框表示Kubernetes平台，Node-1，Node-2，Node-3，Node-4，Node-5是Kubernetes平台内的节点，黑色虚线框部署在Kubernetes平台内的Kafka集群，在Node-1部署KPQM、KPCM、KPDM和KDRM模块，在Node-2、Node3、Node4、Node5上部署KPDM模块，在上部署LPHM和KPDM模块，Kafka集群运行在Node2、Node3、Node4节点上。

如图10所示，本申请另一实施例提供的一种Kafka集群localpv故障状态图，其中，Node4节点kafka-2使用的localpv-5故障。如图11所示，为本申请另一实施例提供的一种Kafka集群localpv恢复后的状态图，即图10故障恢复后的状态图。

Node-5节点配置文件信息如下：

node:Node-5

disks:

-disk:/dev/sdc

partitions:2

class:ssd

mountdir:/mnt/local-disks/ssd

其它节点配置文件与Node-5节点配置文件除节点信息外其余信息相同。

本实施例的步骤如下：

A、各节点分别导入配置文件，分别启动LPHM、KPQM、KPCM、KPDM和KDRM；

B、LPHM读取配置文件中的信息，根据配置信息将Node-5节点上的/dev/sdc存储设备，平均分成2个分区并挂载到/mnt/local-disks/ssd的子目录下，Kubernetes平台组件将localpv-6、localpv-7安装成功，Node-2、Node-3、Node-4节点分别将localpv-8、localpv-9，localpv-10、localpv-11，localpv-12、localpv-13安装成功

C、KPQM获取图9中3个Kafka pod信息，包括名称、PVC、所属节点，例如，kafka-0，pvc-0、pvc-1，node-2，其它pod节点类似；

E、KPCM将获取的C、D两步骤的信息，分别导入图10中的各个KPDM模块，Node-1节点中的KPDM通过kubectl命令获取kubernetes平台的节点状态信息，Node-2、Node-3、Node-4节点中的KPDM通过dd命令测试本节点localpv读写功能，检测到localpv-5不可读写故障，进入图10所示状态，导出不健康的localpv-5到KPCM模块；

F、KPCM根据不健康的localpv-5查找到kafka-2pod，然后查找到kafka-2pod的pvc-4、pvc-5两个PVC，对于localpv-5绑定的pvc-5，核查步骤B中创建的locapv-12、localpv-13空间大于等于pvc-5的声明空间，核查结果存在localpv-13空间大于pvc-5声明的空间，标记该pvc-5和localpv-5删除；

G、核查Kafka除kafka-2pod均健康，KPCM则使用kubectl delete命令删除kafka-2pod、标记为删除的pvc-5和标记为删除的localpv-5；

H、KPCM向Kubernetes平台发送重启kafka-2pod的请求，kafka-2pod将在原节点Node-5重启，重新创建pvc-5，并与Node-5节点的localpv-13绑定。

I、KDRM使用kafka自带的kafka-configs.sh脚本工具设置kafka follower副本向leader副本同步数据的速度，并依赖kafka自身的副本恢复机制恢复kafka-2pod的localpv-13的数据，数据恢复完成后，kafka集群正常运行，进入图11的状态。

实施例4

请参阅图5，为本申请提供的一种Kafka集群故障恢复装置结构框图；包括：

辅助模块1，用于根据预设的配置文件利用Kubernetes平台创建备份的本地存储卷；

查询模块2，用于获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述Kafka Pod所使用的PVC；

检测模块3，用于检测每个所述Kafka Pod所属节点和所述Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；

控制模块4，用于解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系；

数据恢复模块5，用于将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷用以恢复Kafka集群故障。

在此，需要说明的是，所述控制模块4，还用于根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬性需求。

其中，还需要说明的是，Kafka集群故障恢复装置与Kafka集群故障恢复方法为一一对应的关系，在此，各个模块与上述流程步骤所涉及的技术细节与技术效果均相同，在此不用一一赘述，请参照上述Kafka集群故障恢复方法。

实施例5

下面参考图12，其示出了适于用来实现本公开实施例的电子设备(例如终端设备或服务器600的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图12示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图12所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图12示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开实施例的方法中限定的上述功能

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：利用Kubernetes平台内的配置文件信息创建备份的本地存储卷；获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述节点内的PVC；检测每个所述Kafka Pod所属节点和所述Kafka Pod关联的本地存储卷的状态生成状态异常的节点或/和状态异常的本地存储卷；将状态异常的节点或/和状态异常的本地存储卷的数据同步到备份的本地存储卷用以恢复Kafka集群故障。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

综上所述，本申请在Kubernetes平台内设置自动检测Kafka集群故障和自动恢复Kafka集群故障的机制，一方面，提升了Kafka集群使用LocalPV存储系统可靠性和稳定性；另一方面，也提高了维护效率，节省了维护成本。所以，本申请有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本申请。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本申请所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。

Claims

1.一种Kafka集群故障恢复方法，其特征在于，所述方法包括以下步骤：

获取Kubernetes集群内所有Kafka Pod名称、所述Kafka Pod对应节点以及所述KafkaPod所使用的PVC；

2.根据权利要求1所述的Kafka集群故障恢复方法，其特征在于，所述解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系的步骤之前，还包括：

根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬性需求。

3.根据权利要求2所述的Kafka集群故障恢复方法，其特征在于，所述根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬件需求步骤，包括：

4.根据权利要求2或3所述的Kafka集群故障恢复方法，其特征在于，所述根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬件需求步骤，包括：

5.根据权利要求1所述的Kafka集群故障恢复方法，其特征在于，所述解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系的步骤，包括：

根据Kafka集群状态删除状态异常节点的Kafka Pod和对应的PVC，利用新节点创建删除的所述Kafka Pod和对应的PVC，建立新节点内PVC与备份的本地存储卷之间的绑定关系。

6.根据权利要求1所述的Kafka集群故障恢复方法，其特征在于，所述解除状态异常的所述Kafka Pod所使用的PVC与关联的本地存储卷之间的绑定关系，并与备份的本地存储卷建立绑定关系的步骤，包括：

7.一种Kafka集群故障恢复装置，其特征在于，所述装置包括：

8.根据权利要求7所述的Kafka集群故障恢复装置，其特征在于，所述控制模块，还用于根据所述状态异常的节点或/和状态异常的本地存储卷核查备份的本地存储卷的空间与所属节点是否满足恢复的硬性需求。

9.一种电子设备，其特征在于：包括：

一个或多个处理装置；

存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置实现如1至6中任一所述Kafka集群故障恢复方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序用于使所述计算机执行权利要求1至6中任一所述Kafka集群故障恢复方法。