k8s Pod 容器探针(probe)

内容纲要

概述

探针是用来定期对容器的健康状态进行检查,根据探针结果来决定是否重启Pod和是否将流量转发给Pod。

检查机制

探针概述

目前k8s提供了四种探针机制,exec,grpc,httpGet,tcpSocket。

exec可以理解为自定义探针,当k8s其他三种探针机制不支持对自己的应用检查时,可以使用exec方式自己编写健康检查的探针。比如:你启动了一个应用,没有网络通讯能力那么可以使用exec来执行shell脚本或者其他工具来实现或者udp应用。

grpc是Google对自己东西的支持,对于基于grpc实现的应用可以使用这种方式。

httpGet是我们业务开发中比较常用的方式,并且对于后端同学使用spring boot的actuator就可以实现三个探针。

tcpSocket:对于TCP应用可以使用这个检查机制。

k8s官网对四种探针机制的说明

  1. exec
    在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

  2. grpc
    使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 "SERVING",则认为诊断成功。

  3. httpGet
    对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。

  4. tcpSocket
    对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。 如果远程系统(容器)在打开连接后立即将其关闭,这算作是健康的。

探针结果

  1. success
  2. Failure
  3. Unknown

为了满足以上三种探针结果,这就要求我们应用提供的探针接口返回数据满足探针要求。

httpGet

我们先来看http服务,http接口状态码返回200-399,则k8s认为success, 其他状态码为失败,最后接口无法调用或超时为Uknow。

Http状态码 k8s 状态
200~399 success
其他 failure
timeout unknown

exec 探针

exec执行的命令成功则success,否则失败。一般理解为执行的命令返回0表示成功,其他为失败。

tcpSocket

在探测服务时,k8s会尝试打开tcp socket端口,打开成功则成功,否则失败。

三种探针类型

  1. livenessProbe
  2. readinessProbe
  3. startupProbe
探针 作用
Liveness 存活,容器是否正在运行,没有运行重启
Readiness 就绪,是否可以将流量转发给容器,就绪转发流量,未就绪剔出流量转发列表
Startup 启动,容器是否启动

三种探针的关系

探针配置

探针时间配置

参数 作用
initialDelaySeconds 初始延迟秒,容器启动后启动存活态探针之前的秒数
terminationGracePeriodSeconds Pod 需要在探针失败时体面终止所需的时间长度(以秒为单位),为可选字段
periodSeconds 探针的执行周期(以秒为单位)。默认为 10 秒。最小值为 1。
timeoutSeconds 探针超时的秒数。默认为 1 秒。最小值为 1。
failureThreshold 探针成功后的最小连续失败次数,超出此阈值则认为探针失败。默认为 3。最小值为 1。
successThreshold 探针失败后最小连续成功次数,超过此阈值才会被视为探针成功。默认为 1。 存活性探针和启动探针必须为 1。最小值为 1。

探针时间关系

liveness探针

下图展示了liveness探针的时间线图。
livesness探针的配置的failureThreshold为3,

  1. 第一次探针请求成功
  2. 第二次,第三次和第四次请求失败
  3. Pod会在第四次请求后重启
    file
    假设Pod依然没有重启成功,那么由于liveness探针而进行第二次重启需要经过的最短时间为:
    time = initialDelaySeconds + failureThreshold – 1 periodSeconds + timeoutSeconds

假设在正常运行情况下,Pod已经稳定运行了一段时间,则initialDelaySeconds已经不用考虑。在这种情况下,Pod故障和Pod重启之间的最短时间为:
time = failureThreshold – 1 periodSeconds – timeoutSeconds

如下图所示,鼓掌可能发生在探测之前,也可能发生在探测之后。如果periodTime很长,是的对Pod的干扰最小,那么Pod重启启动前的时间可能导致在重启和之前添加额外的periodSeconds时间。
file

failedureThreshold参数必须谨慎设置。如果设置的太高,则存储在Pod发生故障且没有重启时浪费时间。如果设置的太低,那么可能导致Pod过早重启。

readiness探针

对于readiness探针,failureThreshold参数定义了在经过多少次失败之后从EndPoint中将Pod移除。

假设readiness探针的failureThreshold设置的值为5,默认successThreshold为1,那么如下图所示:刚开始Pod先连续经历了三次探测失败,紧接着一次探测成功。一次成功探测会将之前探测失败的次数清零,之后再连续经历5次探测失败后将Pod移除EndPoint,也就是负载均衡列表。
file
将Pod从EndPoint中移除过后,k8s依然会根据配置的时间间隔对Pod进行探测,在探测成功后且连续探测成功次数大于等于successThreshold,那么k8s会将Pod重新加入EndPoint并转发流量,如下图所示:
file

参考

  1. Liveness and Readiness Probes

发表评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部