Kubernetes的三种探针

最新推荐文章于 2025-05-07 19:06:51 发布

smile.ding

最新推荐文章于 2025-05-07 19:06:51 发布

阅读量812

点赞数

分类专栏： Kubenetes 文章标签： kubernetes docker 容器

本文链接：https://blog.youkuaiyun.com/weixin_43934075/article/details/127078365

版权

Kubenetes 专栏收录该内容

3 篇文章

订阅专栏

1. 探针介绍

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为一些意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，或者即便发生问题后也可以快速重启等机制，就成为了重中之重的事情。考虑到这点 kubernetes 推出了活性探针机制。

2. LivessProbe

livenessProbe：存活性探针，用于判断容器是不是健康，如果不满足健康条件，那么 Kubelet 将根据 Pod 中设置的 restartPolicy 来判断 Pod 是否要进行重启操作。livenessProbe按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)，来判断容器是不是正常。如果探测不到，代表容器不健康（可以配置连续多少次失败才记为不健康），则 kubelet 会杀掉该容器，并根据容器的重启策略做相应的处理。如果未配置存活探针，则默认容器启动为通过（Success）状态。即探针返回的值永远是 Success。Success后pod状态是RUNING。

3. ReadinessProbe

readinessProbe：就绪性探针，用于判断容器内的程序是否存活（或者说是否健康），只有程序(服务)正常，容器开始对外提供网络访问（启动完成并就绪）。容器启动后按照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中。

4. StartupProbe

startupProbe：启动探针，k8s 在1.16版本后增加的新探针，主要解决在复杂的程序中，程序启动较慢的问题。如果三个探针同时存在，先执行startupProbe探针，其他两个探针将会被暂时禁用，直到pod满足startupProbe探针配置的条件，其他2个探针启动，如果不满足按照规则重启容器。另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而startupProbe探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

5. LivessProbe和ReadinessProbe的区别

readinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同：

readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除；
livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。

6. 三种探针的使用方法

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

探针探测结果有以下值：

Success：表示通过检测；
Failure：表示未通过检测；
Unknown：表示检测没有正常进行。

7. 三种探针的相关属性

initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0 秒，最小值是 0；
periodSeconds：执行探测的时间间隔（单位是秒），默认为 10s，单位“秒”，最小值是 1；
timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是 1；
successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为 1，在 Liveness 探针中必须为 1，最小值为 1；
failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3，最小值为 1。

注：initialDelaySeconds在readinessProbe中其实可以不用配置，不配置默认pod刚启动，开始进行readinessProbe探测，但那有怎么样，除了 startupProbe，readinessProbe和livenessProbe运行在pod的整个生命周期，刚启动的时候readinessProbe检测失败了，只不过显示READY状态一直是0/1，readinessProbe失败并不会导致重启pod，只有startupProbe、livenessProbe失败才会重启pod。而等到服务真正启动后，检查success成功后，READY状态自然正常。