Kubernetes Probes 介绍

探针简介

  • 存活性探测 (Liveness probes): 存活性探针,用于判断容器是不是健康,如果不满足健康条件,那么 Kubelet 将根据 Pod 中设置的 restartPolicy (重启策略)来判断,Pod 是否要进行重启操作。

    LivenessProbe 按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等),来判断容器是不是正常。如果探测不到,代表容器不健康(可以配置连续多少次失败才记为不健康),则 kubelet 会杀掉该容器,并根据容器的重启策略做相应的处理。如果未配置存活探针,则默认容器启动为通过(Success)状态。即探针返回的值永远是 Success。即 Success 后 pod 状态是 RUNING

  • 就绪性探测 (Readiness probes): 就绪性探针,用于判断容器内的程序是否存活(或者说是否健康),只有程序(服务)正常, 容器开始对外提供网络访问(启动完成并就绪)。

    容器启动后按照 ReadinessProbe 配置进行探测,无问题后结果为成功即状态为 Success。pod 的 READY 状态为 true,从 0/1 变为 1/1。如果失败继续为 0/1,状态为 false。若未配置就绪探针,则默认状态容器启动后为 Success。对于此 pod、此 pod 关联的 Service 资源、EndPoint 的关系也将基于 Pod 的 Ready 状态进行设置,如果 Pod 运行过程中 Ready 状态变为 false,则系统自动从 Service 资源 关联的 EndPoint 列表中去除此 pod,届时 service 资源接收到 GET 请求后,kube-proxy 将一定不会把流量引入此 pod 中,通过这种机制就能防止将流量转发到不可用的 Pod 上。如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。kube-proxy 也将有概率通过负载机制会引入流量到此 pod 中。

  • 启动探测 (Startup Probes): 对于旧应用需要更长的启动时间,这时候既不想重启应用也不想让请求访问进来,可以设置启动探测给足够的启动时间保证应用启动成功

执行顺序

可以自定义在 pod 启动时是否执行这些检测,如果不设置,则检测结果均默认为通过;

如果设置,则顺序为: startupProbe --> readinessProbe --> livenessProbe

但是真的是上面的顺序嘛? 官方文档上却说不是,其中有一段说到。

livenessProbe 不会等待 readinessProbe 成功。如果你想在执行 livenessProbe 之前等待,你应该使用 initialDelaySeconds 或 startupProbe。

所以真正的顺序是:startupProbe --> readinessProbe(livenessProbe)

readinessProbe 和 livenessProbe 之间是异步并发的。

LivenessProbe 与 ReadinessProbe 使用

探测方法

LivenessProbe 和 ReadinessProbe 两种探针都支持下面三种探测方法:

  • ExecAction:在容器中执行指定的命令,如果执行成功,退出码为 0 则探测成功。
  • HTTPGetAction:通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法,如果响应的状态码大于等于 - 200 且小于 400,则认为容器 健康。
  • TCPSocketAction:通过容器的 IP 地址和端口号执行 TCP 检 查,如果能够建立 TCP 连接,则表明容器健康。

探测参数

LivenessProbe 和 ReadinessProbe 两种探针的相关属性
探针(Probe)有许多可选字段,可以用来更加精确的控制 Liveness 和 Readiness 两种探针的行为(Probe):

  • initialDelaySeconds:容器启动后要等待多少秒后就探针开始工作,单位“秒”,默认是 0 秒,最小值是 0

  • periodSeconds:执行探测的时间间隔(单位是秒),默认为 10s,单位“秒”,最小值是 1

  • timeoutSeconds:探针执行检测请求后,等待响应的超时时间,默认为 1s,单位“秒”,最小值是 1

  • successThreshold:探针检测失败后认为成功的最小连接成功次数,默认为 1s,在 Liveness 探针中必须为 1s,最小值为 1s。

  • failureThreshold:探测失败的重试次数,重试一定次数后将认为失败,在 readiness 探针中,Pod 会被标记为未就绪,默认为 3s,最小值为 1s

    提示:initialDelaySeconds 在 ReadinessProbe 其实可以不用配置,不配置默认 pod 刚启动,开始进行 ReadinessProbe 探测,等服务启动后并检查 success 成功后,READY 状态自然正常。

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1
kind: Pod
metadata:
name: liveness-http
labels:
test: liveness
spec:
containers:
- name: liveness
image: test.com/test-http-prober:v0.0.1
LivenessProbe:
failureThreshold: 5 #检测失败5次表示未就绪
initialDelaySeconds: 20 #延迟加载时间
periodSeconds: 10 #重试时间间隔
timeoutSeconds: 5 #超时时间设置
successThreshold: 2 #检查成功为2次表示就绪
httpGet:
port: 8082
path: /status/health

参考


Kubernetes Probes 介绍
https://garychow-lgtm.github.io/zh-CN/2024/07/31/Kubernetes-Probes/
作者
Gary Chow (Yimin Cao)
发布于
2024年7月31日
许可协议