应用程序启动期间Kubernetes livenessProbe关闭

时间:2016-09-05 13:45:11

标签: timeout kubernetes startup probe

我正在使用:

  

kubernetes 1.3.6

..将此部分放在我的应用程序的部署文件中:

    livenessProbe:
      httpGet:
        path: /liveness
        port: 8082
      initialDelaySeconds: 120

..所以当我描述pod时我得到了这个

Liveness: http-get http://:8082/liveness delay=120s timeout=1s period=10s #success=1 #failure=3

我的应用程序通常在110-115秒内启动,但有时需要更多(由于数据库延迟,外部服务重试等)。

我看到的问题是,当它需要超过130/140秒(initialDelaySeconds + period)时,kubernetes强制关闭并且pod从头开始重新启动。当你有很多副本(50-60)时,这意味着完整部署有时需要比正常部署多10-15分钟。显然,解决方案是增加 initialDelaySeconds ,但随后所有部署将花费更多时间。

我看看这里和那里似乎没有解决这个问题: http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_probe

理想情况下,我希望能够以相反的方式运行:不是" initialDelaySeconds",而是最大时间来启动pod。如果时间过去了,kubernetes会强制关闭pod并尝试另一次。

2 个答案:

答案 0 :(得分:4)

我最终得到了一个很好的解决方案,目前完美无缺!

我设置:

  • readinessProbe.initialDelaySeconds:等于应用程序的最短启动时间
  • livenessProbe.initialDelaySeconds:等于应用程序的最大启动时间+几秒钟

因此kubernetes(在readinessProbe.initialDelaySeconds之后)开始检查就绪探针,以便将pod添加到平衡中。 然后(在livenessProbe.initialDelaySeconds之后)它开始检查活动探测,以防pod需要重新启动。

答案 1 :(得分:0)

嗯,看起来你正在谈论的时间实际上就是那里,而不是明确的。

您要查找的时间的公式为

<德尔> initialDelaySeconds + period * (failureTreshold - 1)

-1因为探测是在initialDelaySeconds之后执行的。您可以通过更改这3个值来调整maximumAmountOfTime(您想要的参数)。

编辑:在OP评论之后,上面的答案是错误的,似乎增加initialDelaySeconds是你现在唯一可以做的事情。