startupProbe存在的意义是什么？

startupProbe存在的意义是什么？

引言

今天在整理思惟导图的时候忽然发现有个我不知道的探针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：×××