kubernetes系列之八：Kubernetes的liveness和readiness探测

一、前言

在基于容器云的应用程序部署中，具体POD的生命周期根据各种环境状况有很大不同，POD内部各个容器的状态，container依赖的上游或者周边服务的状态都会对POD作为最终服务实体的服务能力造成影响，所以需要有一个机制来根据container不同的状态来决定POD能否继续存在或者能否加入服务列表对外提供服务。Kubernetes的liveness和readiness探测就是为了解决这个问题产生的。

根据你对POD里面的container代表的不正确业务状态进行不同程度的分级标记，有些不正确业务状态出现的时候，可能需要将整个POD重启，而有些不正确业务状态出现后，则可能不需要重启整个POD，而是需要让POD停止对外服务，等它恢复到正常状态。

转载自https://blog.csdn.net/cloudvtech

二、livenes探测

一个程序在长时间运行后或者有bug trigger的情况下，会进入不正常的状态，这个不正常状态是如此严重，以至于我们需要将容器内的进程杀死，重启整个容器/POD，使POD恢复到最初始的状态。liveness指令可以让你在系统出现这样的状态时让Kubernetes帮你重启这个POD。

通过kubernetes的livenessProbe配置，可以为POD里面的每一个容器指定一个区分是否要重启容器的条件或者范围，这个条件的瞬时值可以通过定时在容器内执行命令、确认某个TCP端口是否可达或者访问容器暴露的HTTP状态查询端口获得，可以定义在连续的有限次的不满足这个条件的情况下，liveness探测失败，进而重启POD。

livenessProbe支持如下三种探测方式：

• exec：在容器内执行命令
• httpGet：访问容器的http服务，可以指定httpHeaders
• tcpSocket：访问容器的TCP端口

转载自https://blog.csdn.net/cloudvtech

三、readiness探测

readiness探测器的配置方式和liveness是一样的，区别在于它们对于Kubernetes的意义不一样。在readiness探测失败之后，POD和容器并不会被删除，而是会被标记成特殊状态，进入这个状态之后，如果这个POD是在某个serice的endpoint列表里面的话，则会被从这个列表里面清除，以保证外部请求不会被转发到这个POD上。在一段时间之后如果容器恢复正常之后，POD也会恢复成正常状态，也会被加回到endpoint的列表里面，继续对外服务。

转载自https://blog.csdn.net/cloudvtech

四、探测器的配置

kubernetes的探测器有一些精细的配置来更细粒度的控制liveness和readiness探测：

• initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。
• periodSeconds：执行探测的频率，默认是10秒。
• timeoutSeconds：探测超时时间，默认1秒。
• successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功，默认是 1。
• failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败，默认是 3。

探测器配置的调整：

• 在设计readiness和liveness探测器的时候，要和业务场景紧密联系，根据业务需求准确的定义成功或者失败的情况。
• 一些探测控制的值是需要经过计算和测试的，比如initialDelaySeconds可能更下层硬件的速度和不同部署需要载入的事件有关系，需要根据部署进行调整。
• 还有一些探测值在调整的时候需要和组成业务bundle的其它模块一起部署，才能根据不同POD之间的依赖关系进行调整。
• 在不同规模的部署中，这些配置值可能也有很大的不同，需要根据实际情况进行测试和调整。
• 在有些部署中，一个容器里面可能有多个进程(不是最佳实践，但是在legacy系统迁移阶段可能会出现这样的问题)，这时候，怎么样让探测器在一个探测点或者容器里面多个进程的状态，可能就需要有不同的方案去处理(比如在容器内部启动一个状态检查的agent，对所有进程状态进行判断并对外全权代理容器的状态；或者使用Supervisor等管理进程)。

另外，由于探测器的工作机制是定时轮询，而不是事件驱动，所以在进程状态异常、容器状态异常、探测失败和kubernetes最终处理完毕之间会存在一定的时延，这个时延可能会对最终客户端造成不同程度的影响。

转载自https://blog.csdn.net/cloudvtech