Kubernetes中三种探针的作用你真的知道吗？

目录

startupProbe

livenessProbe

readinessProbe

---

之前的一篇文章《Kubernetes中配置livenessProbe、readinessProbe和startupProbe》详细讲解了几种探针的配置方式，本文详细讲解一下几种探针的作用和关系，有很多同学可能没有深入地探究过这几种探针，相信本文会带给你很多不知道的知识。

startupProbe

startupProbe 探针用于确定容器是否已经成功启动，会在容器进入运行状态（Running）后开始检测。主要作用是确保容器在启动过程中完成所有必要的初始化步骤，并且能够正常运行。startupProbe 的引入是为了处理那些启动时间较长的应用程序，避免因为启动时间过长而导致容器被误判为失败并重启。探测成功一次之后 Kubernetes 会认为容器已经成功启动并准备就绪，此时 startupProbe 将停止探测。在 startupProbe 探测成功之前，Kubernetes 不会执行 livenessProbe 和 readinessProbe，意味着在 startupProbe 探测成功之前，容器不会被判定为存活或就绪。关键参数如下：

• initialDelaySeconds：容器启动后等待多少秒开始进行首次探测
• periodSeconds：探测的间隔时间（秒）
• failureThreshold：探测失败的最大次数。如果超过这个次数，容器会被认为启动失败并被重启

如果服务是在容器进入运行状态后即已经提供服务的情况下，initialDelaySeconds 的最好设置为0，或者不设置（不设置的话就意味着使用默认值，为0）。

startupProbe 的 periodSeconds 尽量给的小一点，failureThreshold 的值适当给大一点，以达到及时检测到服务启动的目的，保障服务启动后立即提供服务。

livenessProbe

livenessProb 探针用于检测容器是否处于健康运行状态，主要作用是确保容器在运行过程中保持健康，如果探测失败，Kubernetes 会重启该容器，以恢复其正常运行状态。在容器进入运行状态（Running状态，如果有 startupProbe 探针，在 startupProbe 探针探测成功后）initialDelaySeconds 之后开始进行首次探测，在容器运行期间，按照指定的时间间隔定期执行。关键参数如下：

• initialDelaySeconds：容器启动后等待多少秒开始进行首次探测
• periodSeconds：探测的间隔时间（秒）
• timeoutSeconds：探测超时时间（秒），如果探测在指定时间内未完成，则认为探测失败
• failureThreshold：探测失败的最大次数，如果超过这个次数，容器会被认为不健康，并被重启
• successThreshold：探测成功的最小次数，这个参数一般用于 readinessProbe，对于 livenessProbe 通常保持为 1

readinessProbe

readinessProbe 探针用于检测容器是否已经准备好接收流量，主要作用是确保容器在准备好提供服务之前不会接收任何请求，从而避免服务在未准备好时接收请求导致的错误。在容器进入运行状态（Running状态，如果有 startupProbe 探针，在 startupProbe 探针探测成功后）initialDelaySeconds 之后开始进行首次探测，在容器运行期间，按照指定的时间间隔定期执行。关键参数如下：

• initialDelaySeconds：容器启动后等待多少秒开始进行首次探测
• periodSeconds：探测的间隔时间（秒）
• timeoutSeconds：探测超时时间（秒），如果探测在指定时间内未完成，则认为探测失败
• failureThreshold：探测失败的最大次数，如果超过这个次数，容器会被认为没准备好，并从服务的负载均衡器中移除
• successThreshold：探测成功的最小次数。容器在连续 successThreshold 次探测成功后，会被认为准备好接收流量

探测成功后，会将 pod 加入到 service 的负载均衡器中，开始提供服务。如果探测失败，会将 pod 从 service 的负载均衡器中移除。

如果服务是在容器进入运行状态后即已经提供服务的情况下，initialDelaySeconds 的最好设置为0，或者不设置（不设置的话就意味着使用默认值，为0）。

readinessProbe 的 periodSeconds 尽量给的小一点，failureThreshold 的值适当给大一点，以达到及时检测到服务启动的目的，保障服务启动后立即提供服务。如果 periodSeconds 值比较大，首次探测失败的情况下，后续的探测时间间隔会比较长，不能保障服务启动后立即提供服务。