Question

我正在使用：

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

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

Answer 1

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

我设置：

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

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

Answer 2

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

~~您要查找的时间的公式为~~

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

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

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

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

2 个答案: