K8S配置存活、就绪和启动探测器
如何给容器化部署业务配置合适的探针?
readinessprobe简介
readinessprobe,就绪探针,是k8s中的一个概念。当 readinessprobe 检查通过,表示服务就绪,可以接受流量。当 readinessprobe 检查不通过,表示服务没有就绪,不具备提供服务流量的能力。和我们使用的consul agent的对服务的探活是类似的。
可以使用这些字段精确的控制存活和就绪检测的行为:
initialDelaySeconds
:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是 0 秒,最小值是 0。periodSeconds
:执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。timeoutSeconds
:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。successThreshold
:探测器在失败后,被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。failureThreshold
:当探测失败时,Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
目前 readinessprobe 支持三种探测方式:
- http
- tcp
- exec
这三种我们建议使用http方式,更加准确反应服务的健康状态。
http 探测 demo:
|
tcp demo:
|
最佳实践
对于探针的配置,有一定的最佳实践。
有以下几点:
- ReadinessProbe 要反应业务的真实健康状况。如果有预热逻辑,预热后再让ReadinessProbe 通过检查。
- LivenessProbe 要慎用,LivenessProbe 失败会重启 Pod,不要轻易使用,除非你了解后果并且明白为什么你需要它,参考 Liveness Probes are Dangerous 。
- LivenessProbe 相对ReadinessProbe 条件要更宽松。
如果配置LivenessProbe,注意设置合适的 initialDelaySeconds 值,建议180s或更长,具体根据自己业务启动情况配置。尤其java 应用。
线上配置可以参考如下规则:
|
|
如何检查
readinessprobe通过之前,在ones看到实例的状态为HealthChecking的状态,如果长时间处于HealthChecking状态,需要在pod详情中查看是否有健康检查失败的事件,通常为:Readiness probe failed: xxx
举例:
Readiness probe failed: dial tcp 192.168.158.87:8080: connect: connection refused
参考:https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/