Kubernetes故障排除系统、方法、设备及介质与流程

文档序号:17287680发布日期:2019-04-03 03:41阅读:149来源:国知局
Kubernetes故障排除系统、方法、设备及介质与流程

本发明涉及计算机技术,尤其涉及一种基于kubernetes(由谷歌开发的开源的容器集群编排和管理系统)的容器故障排除系统、方法、设备及介质。



背景技术:

kubernetes是一种容器集群编排和管理的分布式系统,它将容器调度并运行在分布式系统的多个节点上。当容器由于异常问题导致无法正常运行时,kubernetes会反复重启容器,直到容器可以正常运行为止,但如果是由于物理机自身的问题,比如网络故障、硬盘故障等导致容器无法运行,即使kubernetes在同一个节点上反复重启容器。由于容器运行所依赖的外部环境并没有改变,容器也不会启动成功,由此会影响kubernetes的性能。



技术实现要素:

本发明要解决的技术问题是为了克服现有技术中基于kubernetes由于物理机自身的问题使得容器不能正常运行的缺陷,提供一种基于kubernetes的容器故障排除系统、方法、设备及介质。

本发明是通过下述技术方案来解决上述技术问题:

一种基于kubernetes的容器故障排除系统,所述基于kubernetes的容器故障排除系统包括驱逐组件、管理控制模块、调度模块、服务接口模块和若干节点,若干所述节点中包括第一节点,所述第一节点上运行有第一容器和第一管理容器进程;

当所述第一容器运行失败时,所述第一管理容器进程用于对应生成运行失败信息,并发送所述运行失败信息至所述服务接口模块,所述服务接口模块用于接收所述运行失败信息,所述驱逐组件用于读取所述服务接口模块并得到所述运行失败信息,还用于生成驱逐请求以及发送所述驱逐请求至所述服务接口模块,所述服务接口模块用于接收所述驱逐请求,所述第一管理容器进程用于监听所述服务接口模块并得到所述驱逐请求以及删除所述第一容器,并生成删除状态信息,以及发送所述删除状态信息至所述服务接口模块,所述管理控制模块用于监听所述服务接口模块并得到所述删除状态信息,还用于复制所述第一容器得到第二容器,并将所述第二容器发送至所述服务接口模块,所述调度模块用于监听所述服务接口模块得到所述第二容器,并将所述第二容器与若干所述节点中的任意一个绑定,绑定的节点为第二节点,所述第二节点上对应运行有第二管理容器进程,所述调度模块还用于生成绑定状态以及发送所述绑定状态至所述服务接口模块,所述服务接口模块用于接收所述绑定状态,所述第二管理容器进程用于监听所述服务接口模块得到所述绑定状态,并运行所述第二容器。

较佳地,所述驱逐组件用于定期读取所述服务接口模块,并判断是否得到所述运行失败信息,若是,则生成所述驱逐请求。

较佳地,所述管理控制模块还用于设置所述第二容器的属性为绑定至若干所述节点中除所述第一节点之外的其他任意一个节点;所述调度模块还用于根据所述属性将所述第二容器与若干所述节点中除第一节点之外的其他任意一个节点绑定。

较佳地,所述第一容器包括运行状态,所述运行状态包括调度字段、初始化字段和就绪字段,所述调度字段用于标记对应的所述第一容器的调度是否成功,所述第一容器还包括初始化容器和常规容器,所述初始化字段用于标记所述初始化容器是否运行成功,所述就绪字段用于标记所述常规容器是否运行成功;

所述驱逐组件还用于读取所述第一容器的所述运行状态,并判断所述调度字段是否为成功,若是,则判断所述初始化字段是否为失败,若是,则表明得到所述运行失败信息,若否,则判断所述就绪字段是否为失败,若是,则表明得到所述运行失败信息。

一种基于kubernetes的容器故障排除方法,所述基于kubernetes的容器故障排除方法利用上述所述的基于kubernetes的容器故障排除系统实现,所述基于kubernetes的容器故障排除方法包括:

当所述第一容器运行失败时,所述第一管理容器进程对应生成运行失败信息,并发送所述运行失败信息至所述服务接口模块;

所述服务接口模块接收所述运行失败信息;

所述驱逐组件读取所述服务接口模块并得到所述运行失败信息,还生成驱逐请求以及发送所述驱逐请求至所述服务接口模块;

所述服务接口模块接收所述驱逐请求,所述第一管理容器进程监听所述服务接口模块并得到所述驱逐请求以及删除所述第一容器,并生成删除状态信息,以及发送所述删除状态信息至所述服务接口模块;

所述管理控制模块监听所述服务接口模块并得到所述删除状态信息,还复制所述第一容器得到第二容器,并将所述第二容器发送至所述服务接口模块;

所述调度模块监听所述服务接口模块得到所述第二容器,并将所述第二容器与若干所述节点中的任意一个绑定,绑定的节点为第二节点,所述第二节点上对应运行有第二管理容器进程;

所述调度模块生成绑定状态以及发送所述绑定状态至所述服务接口模块;

所述服务接口模块接收所述绑定状态;

所述第二管理容器进程监听所述服务接口模块得到所述绑定状态,并运行所述第二容器。

较佳地,所述驱逐组件读取所述服务接口模块的步骤包括:

所述驱逐组件定期读取所述服务接口模块,并判断是否得到所述运行失败信息,若是,则生成所述驱逐请求。

较佳地,所述还复制所述第一容器得到第二容器的步骤包括:

所述管理控制模块设置所述第二容器的属性为绑定至若干所述节点中除所述第一节点之外的其他任意一个节点;

所述并将所述第二容器与若干所述节点中的任意一个绑定的步骤包括:

所述调度模块根据所述属性将所述第二容器与若干所述节点中除第一节点之外的其他任意一个节点绑定。

较佳地,所述第一容器包括运行状态,所述运行状态包括调度字段、初始化字段和就绪字段,所述调度字段用于标记对应的所述第一容器的调度是否成功,所述第一容器还包括初始化容器和常规容器,所述初始化字段用于标记所述初始化容器是否运行成功,所述就绪字段用于标记所述常规容器是否运行成功;

所述驱逐组件读取所述服务接口模块并得到所述运行失败信息的步骤包括:

所述驱逐组件还读取所述第一容器的所述运行状态,并判断所述调度字段是否为成功,若是,则判断所述初始化字段是否为失败,若是,则表明得到所述运行失败信息,若否,则判断所述就绪字段是否为失败,若是,则表明得到所述运行失败信息。

一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如上所述的基于kubernetes的容器故障排除方法。

一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述所述的基于kubernetes的容器故障排除方法的步骤。

本发明的积极进步效果在于:

本发明通过驱逐组件获取运行失败的第一容器,并发送驱逐请求至第一管理容器进程,第一管理容器进程删除第一容器,管理控制模块复制第一容器得到第二容器,调度模块将第二容器与若干所述节点中的任意一个绑定,绑定的节点为第二节点,第二管理容器进程运行第二节点上的第二容器,从而可以让无法正常运行的容器以一定概率被调度到其他节点上,以被重新调度,避免无法正常运行的容器在同一个节点上反复重启也不能运行的问题,因为基于kubernetes中每个节点被选择的概率相同,所以重新调度的策略在一定概率上保证重新生成的第二容器被调度到其他节点上,集群中节点数量越多,第二容器被调度到其他节点的概率越大。

附图说明

图1为本发明的实施例1的基于kubernetes的容器故障排除系统的模块示意图。

图2为本发明的实施例3的基于kubernetes的容器故障排除方法的流程图。

图3为本发明的实施例5的电子设备的结构示意图。

具体实施方式

下面通过实施例的方式进一步说明本发明,但并不因此将本发明限制在所述的实施例范围之中。

实施例1

本实施例提供一种基于kubernetes的容器故障排除系统,如图1所示,基于kubernetes的容器故障排除系统包括驱逐组件1、管理控制模块(controllermanager模块)2、调度模块(scheduler模块)3、服务接口模块(apiserver模块)4和若干节点(node)5,其中若干节点5中包括第一节点511,第一节点上运行有第一容器(pod)512和第一管理容器进程(kubelet进程)513。

当第一容器512运行失败时,第一管理容器进程513用于对应生成运行失败信息,并发送运行失败信息至服务接口模块4,服务接口模块4用于接收运行失败信息,驱逐组件1用于读取服务接口模块4并得到运行失败信息,还用于生成驱逐(evict)请求以及发送驱逐请求至服务接口模块4,服务接口模块4用于接收驱逐请求,第一管理容器进程513用于监听服务接口模块4并得到驱逐请求以及删除第一容器512,并生成删除状态信息,以及发送删除状态信息至服务接口模块4,管理控制模块2用于监听服务接口模块4并得到删除状态信息,还用于复制第一容器512得到第二容器522,并将第二容器522发送至服务接口模块4,调度模块3用于监听服务接口模块4得到第二容器522,并将第二容器522与若干节点5中的任意一个绑定,绑定的节点为第二节点521,第二节点521上对应运行有第二管理容器进程523,调度模块3还用于生成绑定状态以及发送绑定状态至服务接口模块4,服务接口模块4用于接收绑定状态,第二管理容器进程523用于监听服务接口模块4得到绑定状态,并运行第二容器522。

本实施例通过驱逐组件获取运行失败的第一容器,并发送驱逐请求至第一管理容器进程,第一管理容器进程删除第一容器,管理控制模块复制第一容器得到第二容器,调度模块将第二容器与若干所述节点中的任意一个绑定,绑定的节点为第二节点,第二管理容器进程运行第二节点上的第二容器,从而可以让无法正常运行的容器以一定概率被调度到其他节点上,以被重新调度,避免无法正常运行的容器在同一个节点上反复重启也不能运行的问题,因为基于kubernetes中每个节点被选择的概率相同,所以重新调度的策略在一定概率上保证重新生成的第二容器被调度到其他节点上,集群中节点数量越多,第二容器被调度到其他节点的概率越大。

实施例2

本实施例提供一种基于kubernetes的容器故障排除系统,本实施例与实施例1相比,其区别在于,驱逐组件1用于定期读取服务接口模块4,并判断是否得到运行失败信息,若是,则生成驱逐请求。

更具体地,第一容器512包括运行状态,运行状态包括调度(scheduler)字段、初始化(initial)字段和就绪(ready)字段,调度字段用于标记对应的第一容器512的调度是否成功,第一容器512还包括初始化(initial)容器和常规(regular)容器,初始化字段用于标记初始化容器是否运行成功,就绪字段用于标记常规容器是否运行成功。

驱逐组件1还用于读取第一容器512的运行状态,并判断调度字段是否为成功,若是,则判断初始化字段是否为失败,若是,则表明得到运行失败信息,若否,则判断就绪字段是否为失败,若是,则表明得到运行失败信息。

驱逐组件只需要判断以上几种情况的状态字段的取值,即可检测出未成功运行的容器。

调度模块3执行重新调度时,每个节点被选择的概率相同,如果调度模块3选择了将第二容器522绑定至第一节点511,则第二容器522会在第一节点511上创建,那么第二容器522仍然无法正常运行。那么重调度策略只能在一定概率上保证第二容器522被调度到其他节点,kubernetes集群中的节点数量越多,第二容器522被调度到其他节点的概率越大。

优选地,为进一步提高第二容器被调度到其他节点的概率,管理控制模块2还用于设置第二容器的属性为绑定至若干节点5中除第一节点511之外的其他任意一个节点;调度模块3还用于根据属性将第二容器与若干节点5中除第一节点511之外的其他任意一个节点绑定。

本实施例的第二容器被调度成功的概率更大。

驱逐组件无法区分第一容器未成功运行的原因是由于第一节点的物理机环境问题导致,还是由于第一容器自身的程序问题导致,驱逐组件是在不严格区分这两种原因的情况下触发的节点的驱逐。

实施例3

本实施例提供一种基于kubernetes的容器故障排除方法,基于kubernetes的容器故障排除方法利用实施例1中的基于kubernetes的容器故障排除系统实现,如图2所示,基于kubernetes的容器故障排除方法包括:

步骤201、当第一容器运行失败时,第一管理容器进程对应生成运行失败信息,并发送运行失败信息至服务接口模块。

步骤202、服务接口模块接收运行失败信息。

步骤203、驱逐组件读取服务接口模块并得到运行失败信息,还生成驱逐请求以及发送驱逐请求至服务接口模块。

步骤204、服务接口模块接收驱逐请求,第一管理容器进程用于监听服务接口模块并得到驱逐请求以及删除第一容器,并生成删除状态信息,以及发送删除状态信息至服务接口模块。

步骤205、管理控制模块监听服务接口模块并得到删除状态信息,还复制第一容器得到第二容器,并将第二容器发送至服务接口模块。

步骤206、调度模块监听服务接口模块得到第二容器,并将第二容器与若干节点中的任意一个绑定,绑定的节点为第二节点,第二节点上对应运行有第二管理容器进程。

步骤207、调度模块生成绑定状态以及发送绑定状态至服务接口模块。

步骤208、服务接口模块接收绑定状态。

步骤209、第二管理容器进程监听服务接口模块得到绑定状态,并运行第二容器。

本实施例通过驱逐组件获取运行失败的第一容器,并发送驱逐请求至第一管理容器进程,第一管理容器进程删除第一容器,管理控制模块复制第一容器得到第二容器,调度模块将第二容器与若干所述节点中的任意一个绑定,绑定的节点为第二节点,第二管理容器进程运行第二节点上的第二容器,从而可以让无法正常运行的容器以一定概率被调度到其他节点上,以被重新调度,避免无法正常运行的容器在同一个节点上反复重启也不能运行的问题,因为基于kubernetes中每个节点被选择的概率相同,所以重新调度的策略在一定概率上保证重新生成的第二容器被调度到其他节点上,集群中节点数量越多,第二容器被调度到其他节点的概率越大。

实施例4

本实施例提供一种基于kubernetes的容器故障排除方法,本实施例与实施例3相比,其区别在于,步骤303中的驱逐组件读取服务接口模块并得到运行失败信息的步骤还包括:

驱逐组件定期读取服务接口模块,并判断是否得到运行失败信息,若是,则生成驱逐请求。

更具体地,第一容器包括运行状态,运行状态包括调度字段、初始化字段和就绪字段,调度字段用于标记对应的第一容器的调度是否成功,第一容器还包括初始化容器和常规容器,初始化字段用于标记初始化容器是否运行成功,就绪字段用于标记常规容器是否运行成功。

步骤303中的驱逐组件读取服务接口模块并得到运行失败信息的步骤还包括:

驱逐组件还读取第一容器的运行状态,并判断调度字段是否为成功,若是,则判断初始化字段是否为失败,若是,则表明得到运行失败信息,若否,则判断就绪字段是否为失败,若是,则表明得到运行失败信息。

驱逐组件只需要判断以上几种情况的状态字段的取值,即可检测出未成功运行的容器。

调度模块执行重新调度时,每个节点被选择的概率相同,如果调度模块选择了将第二容器绑定至第一节点,则第二容器会在第一节点上创建,那么第二容器仍然无法正常运行。那么重调度策略只能在一定概率上保证第二容器被调度到其他节点,kubernetes集群中的节点数量越多,第二容器被调度到其他节点的概率越大。

优选地,为进一步提高第二容器被调度到其他节点的概率,

步骤305中的复制第一容器得到第二容器的步骤还包括:

管理控制模块设置第二容器的属性为绑定至若干节点中除第一节点之外的其他任意一个节点;

并将第二容器与若干节点中的任意一个绑定的步骤包括:

调度模块根据属性将第二容器与若干节点中除第一节点之外的其他任意一个节点绑定。

驱逐组件无法区分第一容器未成功运行的原因是由于第一节点的物理机环境问题导致,还是由于第一容器自身的程序问题导致,驱逐组件是在不严格区分这两种原因的情况下触发的节点的驱逐。

实施例5

图3为本发明实施例5提供的一种电子设备的结构示意图。所述电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现实施例3的基于kubernetes的容器故障排除方法。图3显示的电子设备30仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。

如图3所示,电子设备30可以以通用计算设备的形式表现,例如其可以为服务器设备。电子设备30的组件可以包括但不限于:上述至少一个处理器31、上述至少一个存储器32、连接不同系统组件(包括存储器32和处理器31)的总线33。

总线33包括数据总线、地址总线和控制总线。

存储器32可以包括易失性存储器,例如随机存取存储器(ram)321和/或高速缓存存储器322,还可以进一步包括只读存储器(rom)323。

存储器32还可以包括具有一组(至少一个)程序模块324的程序/实用工具325,这样的程序模块324包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。

处理器31通过运行存储在存储器32中的计算机程序,从而执行各种功能应用以及数据处理,例如本发明实施例3所提供的基于kubernetes的容器故障排除方法。

电子设备30也可以与一个或多个外部设备34(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口35进行。并且,模型生成的设备30还可以通过网络适配器36与一个或者多个网络(例如局域网(lan),广域网(wan)和/或公共网络,例如因特网)通信。如图所示,网络适配器36通过总线33与模型生成的设备30的其它模块通信。应当明白,尽管图中未示出,可以结合模型生成的设备30使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid(磁盘阵列)系统、磁带驱动器以及数据备份存储系统等。

应当注意,尽管在上文详细描述中提及了电子设备的若干单元/模块或子单元/模块,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本发明的实施方式,上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之,上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

实施例6

本实施例提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现实施例3所提供的基于kubernetes的容器故障排除方法的步骤。

其中,可读存储介质可以采用的更具体可以包括但不限于:便携式盘、硬盘、随机存取存储器、只读存储器、可擦拭可编程只读存储器、光存储器件、磁存储器件或上述的任意合适的组合。

在可能的实施方式中,本发明还可以实现为一种程序产品的形式,其包括程序代码,当所述程序产品在终端设备上运行时,所述程序代码用于使所述终端设备执行实现实施例3所述的基于kubernetes的容器故障排除方法中的步骤。

其中,可以以一种或多种程序设计语言的任意组合来编写用于执行本发明的程序代码,所述程序代码可以完全地在用户设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户设备上部分在远程设备上执行或完全在远程设备上执行。

虽然以上描述了本发明的具体实施方式,但是本领域的技术人员应当理解,这仅是举例说明,本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下,可以对这些实施方式做出多种变更或修改,但这些变更和修改均落入本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1