目录
之前的一篇文章《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 值比较大,首次探测失败的情况下,后续的探测时间间隔会比较长,不能保障服务启动后立即提供服务。