startupProbe存在的意义是什么？

标签：思维导图   根据   delay   运行   res   period   存在   email   的区别   

引言

今天在整理思维导图的时候突然发现有个我不知道的探针startupProbe，于是查了下官方是这样解释的：可以定义一个启动探针，该探针将推迟所有其他探针，直到 Pod 完成启动为止。看完这句话有蒙圈于是提出了下面这个问题：

startupProbe 启动探针存在的意义是不是： 如果服务A启动需要1分钟 ，我们存活探针探测的时候设置的是initialDelaySeconds 10s后开始探测，然后她探测的时候发现服务不正常，然后就开始重启Pod陷入死循环，但是如果意义在这个地方，那我们可以把探测时间调整大一点，failureThreshold 把这个也多设置几次就行了啊。 为什么还要单独的设置一个satrtupProbe呢？

经过给大佬讨论得出如下答案

startupProbe的存在意义？

在继续往下看的时候你需要知道这个： startupProbe 和 livenessProbe 最大的区别就是startupProbe在探测成功之后就不会继续探测了，而livenessProbe在pod的生命周期中一直在探测。

如果没有startupProbe探针的话我们只设置livenessProbe探针话会存在如下问题： 一个服务如果前期启动需要很长时间，那么它后面死亡未被发现的时间就越长，为什么会这么说呢？假设我们一个服务A启动完成需要2分钟，那么我们如下开始定义livenessProbe

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 1
initialDelay：5
periodSeconds: 5

如果我们这样定义的话，那pod 5s就会根据重启策略进行一次重启，这个时候你会发现pod一直会陷入死循环，那我们可以按照上面的猜想把配置改成这样

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 6
initialDelay：40
periodSeconds: 5

你肯定会说你看这样不就行了吗？这样的话pod就不会陷入死循环能启动起来了，确实这样pod能够启动起来了，但是你有没有考虑过这样一个问题，当我们启动完成之后，在后期的探测中，你需要6*5=30s才能发现这个pod不可用，这个时候你的服务已经停止运行了30s你才发现，这在生产中有可能是不会被原谅的。
还有就是这边只是我们假设一个服务A需要1分钟才能起来，但是在实际生产中你如何定义这些值呢？？？
针对上面这两个问题引入startupProbe之后都解决了

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 1
initialDelay：5
periodSeconds: 5

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 60
initialDelay：5
periodSeconds: 5

我们这样设置之后，由于启动探针的存在，程序有605s=300s的启动时间，一旦启动探针探测成功之后，就会被livenessProbe接管，这样在运行中出问题livenessProbe就能在15=5s内发现。如果启动探测是3分钟内还没有探测成功，则接受Pod的重启策略进行重启。

上面所描诉的就是kubernetes startupProbe的存在意义？
多希望各位大佬指点：

email： zsf18163201@163.com
wechat：×××

startupProbe存在的意义是什么？

标签：思维导图   根据   delay   运行   res   period   存在   email   的区别   

原文地址：https://blog.51cto.com/13447608/2448070