k8s的就绪探针和存活探针

k8s的就绪探针和存活探针

就绪探针和存活探针

探针的作用

• 就绪探针：一个应用往往需要一段时间来预热和启动，比如一个后端项目的启动需要连接数据库执行数据库迁移等等，一个Spring项目的启动也需要依赖Java虚拟机。即使该过程已启动，您的服务在启动并运行之前也无法运行。应用在完全就绪之前不应接收流量，但默认情况下，Kubernetes会在容器内的进程启动后立即开始发送流量。通过就绪探针探测，直到应用程序完全启动，然后才允许将流量发送到新副本。
• 存活探针：让我们想象另一种情况，当我们的应用在成功启动以后因为一些原因“宕机”，或者遇到死锁情况，导致它无法响应用户请求。 在默认情况下，Kubernetes会继续向Pod发送请求，通过使用存活探针来检测，当发现服务不能在限定时间内处理请求（请求错误或者超时），就会重新启动有问题的pod。

Kubernetes提供了两种探针来检查容器的状态，对于检测到故障服务会被及时自动下线，以及通过重启服务的方式使服务自动恢复。

• Liveliness：存活探针，判断容器是否处于正在运行状态。当服务crash或者死锁等情况发生时，k8s会kill掉容器，然后根据其设置的restart policy进行相关的操作（可能会在本机重新启动容器，或者因为设置k8s QoS，本机没有资源情况下会被分发到其他机器上重新启动）
• Readiness：就绪指针，判断服务是否已经正常工作（即查看容器是否准备好接受Http请求），如果服务没有加载完成或工作异常，服务所在的Pod的IP地址会从服务的Endpoint中移除。也就是说，如果服务没有ready时，会将其从服务的load balancer中移除，不会再接受或响应任何请求。

探测结果：成功（Success）、失败（Failure）、未知（Unknown）

探针类型

探针类型	说明	健康检查标准
ExecAction	容器内部执行shell命令进行探测	shell命令返回0
TCPSocketAction	通过容器的IP、端口执行TCP进行检查	端口是否打开
HTTPGetAction	通过容器的IP、端口、path路径，用http GET方式请求进行检查	200<=响应码<400

服务可用性和自动恢复

• 如果就绪探针（readiness）健康检查失败，故障的服务实例从service endpoint中下线，外部请求将不再转发到该服务上，一定程度上保证正在提供服务的服务的正确性，如果服务自我恢复了（比如网络问题），会自动重新加入service endpoint对外提供服务。
• 如果设置了存活探针（liveliness），对故障服务的容器探测失败，容器会被kill掉，并根据设置的容器重启策略，进行重启容器或在其他机器上重新创建pod。

使用建议

• 一般故障发生后，先下线，再重启。重启后服务正常再上线。所以一般建议设置检查服务（readiness）的时间短于检查容器（liveness）的时间，也可以将检查服务（readiness）的探针与容器（liveness）的探针设置为一致。
• 目的是故障服务先下线（readiness的作用），如果过一段时间还无法自动恢复，那么根据重启策略进行重启（liveness的作用）。

Pod的重启策略：

当pod中一个container处于退出状态(Exited)时，kubelet会根据Pod Spec中设置restartPolicy进行相应操作，重启的策略分别如下：

• Always: 默认的重启策略，只要有一个container处于Exited时，即会重启
• OnFailure：container退出状态不为0时，即会重启。
• Never: 从不重启。

需要重点说明的是：

• 一个pod设置重启策略，适用于pod中全部container。
• 处于退出状态的容器由 kubelet 以五分钟为上限的指数衰减延迟（10秒，20秒，40秒…）重新启动，并在container重启成功十分钟后会重置该值。