一种基于Kubernetes容器应用健康检查的方法及其系统与流程

本发明涉及软件应用运行的程序控制技术领域，具体涉及程序启动，特别是一种基于kubernetes容器应用健康检查的方法。

背景技术：

kubernetes现有的容器健康检查方法分为两种，分别是存活探针(livenessprobe)和就绪探针(readinessprobe),其中，存活探针指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。就绪探针指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与pod匹配的所有service的端点中删除该pod的ip地址，即不会将流量继续导入该pod。

但是现有的两种健康检查方法很难解决一些启动较慢的应用的问题。首先，慢启动的应用有可能因为启动时间过长，在还没启动成功就已经因为健康检查机制而被kubelet杀掉、重启；其次，如果在启动阶段应用出现死锁现象，那么根据现有的健康检查配置，在应用被重启前，有可能要等待一段非常久的时间。

技术实现要素：

本发明的发明目的是，针对上述问题，提供一种基于kubernetes容器应用健康检查的方法，通过新增一种新的健康检查探针，推迟现有的健康检查探针的检查操作，以达到慢启动容器在启动时能快速从死锁或其他故障中快速恢复，也保证了容器在正常的启动流程中不会被错误的重启。

为达到上述目的，本发明所采用的技术方案是：

一种基于kubernetes容器应用健康检查的方法，包括以下内容：

s1、容器启动检测程序：kubernetes组件kubelet采用启动探针周期性的对容器的健康状态进行检测；

s2、容器启动判断程序：根据启动探针的检测结果判断容器是否启动成功；若容器启动成功则执行下一程序，若容器启动失败则对容器进行重新启动或杀掉操作并结束流程；

s3、容器健康检查程序：kubelet采用存活探针和就绪探针分别对容器进行相应的健康检查。

作为一选项，步骤s1的具体内容如下：

s11、kubelet获取新建的pod容器信息；

s12、根据pod容器的探针配置启动启动探针；

s13、配置启动探针的失败阈值和检测周期；其中，kubelet根据启动探针的failurethreshold和periodseconds字段配置启动探针的失败阈值和检测周期；

s14、启动探针根据检查配置选择检查方法；其中，检查方法包括httpget方法、tcp方法、执行命令方法；

s15、采用该检查方法周期性的进行健康检查；具体为，启动探针采用前述所选择的检查方法每periodseconds秒对容器进行一次健康检查。

作为一选项，步骤s2的具体内容如下：

s21、根据健康检查所返回的状态码判断检测结果；若当前的状态码为预置探活成功码，则检测结果为探活成功，容器启动成功，执行下述s23程序；若当前的状态码为预置探活失败码，则检测结果为探活失败，容器当前未启动成功，执行下述s22程序；

s22、计算连续探活失败次数，判断当前的探活失败次数是否达到失败阈值，当连续失败failurethreshold次后，判定容器启动失败，对容器进行重新启动或杀掉操作并结束流程；否则，将容器当前的启动状态containerstatus.started字段继续维持在初始状态false，返回执行周期性的进行健康检查程序；

s23、将容器当前的启动状态containerstatus.started字段由初始状态false更新为true，执行下一程序。

作为一选项，步骤s3中，存活探针和就绪探针与启动探针同时被启动，且，存活探针和就绪探针启动后一直处于抑制状态，并监测容器当前的启动状态containerstatus.started字段，当容器启动成功containerstatus.started字段由初始状态false更新为true后，存活探针和就绪探针解除抑制状态，并分别对容器进行相应的健康检查。

作为一选项，步骤s3中，存活探针和就绪探针在容器启动成功且容器当前的启动状态containerstatus.started字段由初始状态false更新为true后被启动，然后分别对容器进行相应的健康检查。

由于采用上述技术方案，本发明具有以下有益效果：

1.本发明缩短启动耗时较长应用的准备就绪时间，提升启动效率。

2.当应用容器启动阶段发生死锁时，尽快的杀死容器，并重启，提高故障恢复速度。

3.将启动时的健康检查独立出来，可以使得存活探针在容器出现故障时更及时的发现并重启恢复。

附图说明

图1是本发明的健康检查方法流程图。

图2是本发明的健康检查方法实例的流程图。

图3是本发明的健康检查方法实例的运行系统示意图。

图4是本发明的健康检查方法实例的三种探针状态示意图。

具体实施方式

以下结合附图对发明的具体实施进一步说明。

实施例1

如图1所示，本实施例的一种基于kubernetes容器应用健康检查的方法，包括以下内容：

步骤s1、容器启动检测程序：kubernetes组件kubelet采用启动探针周期性的对容器的健康状态进行检测；步骤s1的具体内容如下：

s11、kubelet获取新建的pod容器信息；

s12、根据pod容器的探针配置启动启动探针；

s13、配置启动探针的失败阈值和检测周期；其中，kubelet根据启动探针的failurethreshold和periodseconds字段配置启动探针的失败阈值和检测周期；

s14、启动探针根据检查配置选择检查方法；其中，检查方法包括httpget方法、tcp方法、执行命令方法；其中，检查方法可以选择其中一种或几种组合，当采用几种检查方法组合时设置优先级别，根据优先级别及自检程序排查检查方法运行状况，当运行出错时逐次选择检查方法；

s15、采用该检查方法周期性的进行健康检查；具体为，启动探针采用前述所选择的检查方法每periodseconds秒对容器进行一次健康检查。

步骤s2、容器启动判断程序：根据启动探针的检测结果判断容器是否启动成功；若容器启动成功则执行下一程序，若容器启动失败则对容器进行重新启动或杀掉操作并结束流程；其中，容器启动成功，将启动探针关闭；若容器启动失败，启动探针也停止工作，其他探针也不会进行后续探测；步骤s2的具体内容如下：

s21、根据健康检查所返回的状态码判断检测结果；若当前的状态码为预置探活成功码，则检测结果为探活成功，容器启动成功，执行下述s23程序；若当前的状态码为预置探活失败码，则检测结果为探活失败，容器当前未启动成功，执行下述s22程序；

s22、计算连续探活失败次数，判断当前的探活失败次数是否达到失败阈值，当连续失败failurethreshold次后，判定容器启动失败，对容器进行重新启动或杀掉操作并结束流程；否则，将容器当前的启动状态containerstatus.started字段继续维持在初始状态false，返回前述s15执行周期性的进行健康检查程序；其中，对容器进行重新启动操作是指杀掉并重新启动该容器，对容器进行杀掉操作是指杀掉该容器；

s23、将容器当前的启动状态containerstatus.started字段由初始状态false更新为true，执行下一程序。

步骤s3、容器健康检查程序：kubelet采用存活探针和就绪探针分别对容器进行相应的健康检查。其中，存活探针和就绪探针分别对容器进行相应的健康检查过程均是现有技术，此处不再敖述。

作为一选项，在一实施例中，步骤s3中，存活探针和就绪探针与启动探针同时被启动，且，存活探针和就绪探针启动后一直处于抑制状态，并监测容器当前的启动状态containerstatus.started字段，当容器启动成功containerstatus.started字段由初始状态false更新为true后，响应于该字段更新操作或监测到该字段更新后，存活探针和就绪探针解除抑制状态，并分别对容器进行相应的健康检查。

作为一选项，在一实施例中，步骤s3中，存活探针和就绪探针在容器启动成功且容器当前的启动状态containerstatus.started字段由初始状态false更新为true后被启动，然后分别对容器进行相应的健康检查。

当然，还有单独采用存活探针或就绪探针进行健康检查情形，即，此时的探针配置为配置存活探针和启动探针，或为配置就绪探针和启动探针。

下述将具体举例说明：基于kubernetes容器应用健康检查方法实例

如图3所示，本实例采用3个masternode作为控制节点，控制节点不负责运行工作负载，只有一些kubernetes的组件以容器的形式运行在上面，kubernetes集群加载并运行有若干个模块，包括应用程序接口服务器(apiserver)，控制器管理控制中心(controllermanager)，调度器(scheduler)。每个masternode上的apiserver都会与分布式数据库etcd连接，用于集群内各种资源配置和状态存储。

如图4所示，启动探针(startupprobe)由kubelet组件运行。

其中，apiserver是kubernetes集群附带的组件，能够接收创建新容器和相应探针的请求。

containerstatus是容器附加的属性，用以表示容器当前的启动状态。

如图2所示，该基于kubernetes容器应用健康检查方法由以下步骤组成：

执行步骤1：假设该实例中容器的存活探针、就绪探针和启动探针都已配置，kubelet根据启动探针的配置，周期性地对容器的健康状态进行检测，判断是否启动成功。期间对存活探针和就绪探针进行抑制。

参见图4，该步骤1具体为：

11.kubelet从apiserver获取需要新建的容器信息。

12.根据容器的健康检查探针配置，kubelet分别启动三种健康检查探针。三种健康检查探针包括存活探针和就绪探针、启动探针。

13.根据容器的启动探针的配置，可以选择三种方式对容器进行健康检查，包括1.http请求探活，2.tcp连接探活，3.容器内执行命令探活，该实例以http请求探活作为例子。

14.启动探针每隔periodseconds秒向配置的容器url和端口发送一次httpget请求，如果返回的状态码是200则认为探活成功，将containerstatus.started字段设置为true，表示容器启动成功。如果返回的状态码是非200则认为探活失败，继续维持containerstatus.started字段为false。

其中，容器的当前的启动状态containerstatus.started字段初始默认状态为false状态，即表示容器没有启动成功。存活探针和就绪探针会根据配置的间隔时间，每periodseconds秒探测一次容器启动状态，在启动期间的启动状态一直为false，两种探针保持抑制状态。

执行步骤2，根据启动探针的检测结果判断容器是否启动成功，对pod的容器状态(containerstatus)字段进行更新。

参见图4，该步骤2具体为：

21.启动探针每隔periodseconds秒向配置的容器url和端口发送一次httpget请求，如果返回的状态码是200则认为探活成功，将containerstatus.started字段设置为true，表示容器启动成功。当出现一次成功的探测，就认为容器启动成功。如果返回的状态码是非200则认为探活失败，继续维持containerstatus.started字段为false。

22.当步骤21中的探活连续失败failurethreshold次后，判定容器启动失败，kubelet会将该容器杀死，并根据该容器提前配置好的重启策略控制重新启动该容器。当然，是否重新启动该容器是该提前配置好的重启策略配置的，如配置为重启或不重启。

执行步骤3，kubelet的存活探针和就绪探针根据containerstatus.started决定是否继续保持抑制状态。

参见图4，该步骤3具体为：

31.kubelet在容器创建后，同时启动存活探针和就绪探针，这两种探针在实际健康检查探测前会处于抑制状态下监控containerstatus.started字段。存活探针和就绪探针会每间隔periodseconds秒分别对容器进行相应的健康检查，监控containerstatus.started字段。

32.当监控到containerstatus.started字段为true时，存活探针和就绪探针会解除抑制状态，开始真正的对容器进行探活操作。

如图4所示，只有为容器配置了启动探针的情况，存活探针和就绪探针才会因为containerstatus.started字段默认为false而被抑制。当未配置启动探针的情况，containerstatus.started字段默认为true，存活探针和就绪探针可以直接开始对容器进行健康检查。

如前述，现有技术如果没配置initialdelayseconds字段，那么对于启动时间较长的应用，会发生“启动时间过长，在还没启动成功就已经因为健康检查机制而被kubelet杀掉、重启”现象。如果配置了initialdelayseconds字段，并且设置一个较长的时间，那么对于启动时间较长的应用，会出现“如果在启动阶段应用出现死锁现象，那么根据现有的健康检查配置，在应用被重启前，有可能要等待一段非常久的时间”问题；也就是说，linveness探针会先等待initialdelayseconds秒那么长的时间才开始探测，然后又要等待periodseconds*failurethreshold秒那么长的时间，才会将应用杀死、重启。

为此，该方法新增启动探针，作为一种新的健康检查探针，该启动探针其实和liveness探针和readiness探针是同等级的，相关的可配置字段都可相同，区别点是在启动及检查操作顺序上，startup探针会先启动运行，先检测容器启动状况，并且抑制liveness探针和readiness探针，确保容器启动后再由liveness探针和readiness探针进行健康检查操作，以解决上述问题。

如上述，该方法通过新增启动探针，推迟现有的健康检查探针的检查操作，以达到慢启动容器在启动时能快速从死锁或其他故障中快速恢复，也保证了容器在正常的启动流程中不会被错误的重启。具体优点如下：

1.缩短启动耗时较长应用的准备就绪时间，提升启动效率。

2.当应用容器启动阶段发生死锁时，尽快的杀死容器，并重启，提高故障恢复速度。

3.将启动时的健康检查独立出来，可以使得存活探针在容器出现故障时更及时的发现并重启恢复。

实施例2

基于上述实施例1，下述将说明本实施例的一种基于kubernetes容器应用健康检查系统，详细说明请参见上述实施例1。

本实施例的一种基于kubernetes容器应用健康检查系统，包括以下内容：

容器启动检测模块：用于kubernetes组件kubelet采用启动探针周期性的对容器的健康状态进行检测。具体的，容器启动检测模块包括以下内容：

获取模块：用于kubelet获取新建的pod容器信息；

启动模块：用于根据pod容器的探针配置启动启动探针；

配置模块：用于配置启动探针的失败阈值和检测周期；其中，kubelet根据启动探针的failurethreshold和periodseconds字段配置启动探针的失败阈值和检测周期；

选择模块：用于启动探针根据检查配置选择检查方法；其中，检查方法包括httpget方法、tcp方法、执行命令方法；

周期检查模块：用于采用该检查方法周期性的进行健康检查；具体为，启动探针采用前述所选择的检查方法每periodseconds秒对容器进行一次健康检查。

容器启动判断模块：用于根据启动探针的检测结果判断容器是否启动成功；若容器启动成功则执行下述容器健康检查模块的检查程序，若容器启动失败则对容器进行重新启动或杀掉操作并结束流程。容器启动判断模块包括以下内容：

判断模块：用于根据健康检查所返回的状态码判断检测结果；若当前的状态码为预置探活成功码，则检测结果为探活成功，容器启动成功，执行下述字段更新模块的更新程序；若当前的状态码为预置探活失败码，则检测结果为探活失败，容器当前未启动成功，执行下述失败判定模块的判定程序；

失败判定模块：用于计算连续探活失败次数，判断当前的探活失败次数是否达到失败阈值，当连续失败failurethreshold次后，判定容器启动失败，对容器进行重新启动或杀掉操作并结束流程；否则，将容器当前的启动状态containerstatus.started字段继续维持在初始状态false，返回执行周期检查模块的周期性的进行健康检查程序；

字段更新模块：用于将容器当前的启动状态containerstatus.started字段由初始状态false更新为true，执行下述容器健康检查模块的检查程序。

容器健康检查模块：用于kubelet采用存活探针和就绪探针分别对容器进行相应的健康检查。

作为一选项，容器健康检查模块中，存活探针和就绪探针与启动探针同时被启动，且，存活探针和就绪探针启动后一直处于抑制状态，并监测容器当前的启动状态containerstatus.started字段，当容器启动成功containerstatus.started字段由初始状态false更新为true后，存活探针和就绪探针响应于该字段更新或监测到该字段更新后解除抑制状态，并分别对容器进行相应的健康检查。

作为一选项，容器健康检查模块中，存活探针和就绪探针在容器启动成功且容器当前的启动状态containerstatus.started字段由初始状态false更新为true后被启动，然后分别对容器进行相应的健康检查。

如上述，该系统通过新增启动探针，推迟现有的健康检查探针的检查操作，以达到慢启动容器在启动时能快速从死锁或其他故障中快速恢复，也保证了容器在正常的启动流程中不会被错误的重启。

上述说明是针对本发明较佳可行实施例的详细说明和例证，但这些描述并非用以限定本发明所要求保护范围，凡本发明所提示的技术教导下所完成的同等变化或修饰变更，均应属于本发明所涵盖专利保护范围。