Kubernetes的Pod健康检查

Kubernetes的Pod健康检查

对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe

LivenessProbe探针

用于判读容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理；如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回值永远都是“Success”

ReadinessProbe探针

用户判断容器状态是否启动完成（Ready状态），可以接收请求。如果ReadinesssProbe探针探测到失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在的Pod的Endpoint。

这两种探针有何区别呢？

livenessProbe决定是否重启容器，而ReadinessProbe决定是否将请求转发给容器。

ReadinessProbe的使用场景：

Pod对象启动后，容器应用通常需要一段时间才能完成其初始化过程，例如加载配置或数据，甚至有些程序需要运行某些类的预热过程，若在此阶段完成之前接入客户端的请求，势必会因为等待太久而影响用户体验，这时就需要ReadinessProbe探针。

如果没有将ReadinessProbe探针添加到pod中，它们几乎会立即成为服务端点。如果应用程序需要很长时间才能开始监听传入连接，则在服务启动但尚未准备好接收传入连接时，客户端请求将被转发到该pod。因此，客户端会看到"连接被拒绝"类型的错误。

LivenessProbe三种实现方式：

（1） ExecAction：

说明：

通过在容器内执行一个命令，如果该命令的返回码为0，则表示容器健康。

Pod运行之后，在创建/tmp/health文件的60s之后将删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果将是Fail，则kubelet将杀掉该容器并重启它。

（2） TCPSocketAction

通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表示容器健康。

可以看一下events信息，这里进行了2次自启动

（3） HTTPGetAction

通过容器的IP地址、端口号以及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器状态健康。

对于上面的探测方式，都需要设置initialDelaySeconds和timeoutSeconds

分别表示如下：

initialDelaySeconds

启动容器后进行首次健康检查的等待时间，单位为s

timeoutSeconds

健康检查发送请求后等待响应的超时时间，单位为s。当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。