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

【问题标题】：Kubernetes livenessProbe shutdown during application startupKubernetes livenessProbe 在应用程序启动期间关闭
【发布时间】：2016-09-10 00:04:36
【问题描述】：

我正在与：

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 秒内启动，但有时需要更多时间（由于 DB 延迟、外部服务重试等）。

我看到的问题是，当花费超过 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 关闭并尝试另一次。

【问题讨论】：

标签： timeout kubernetes startup probe

【解决方案1】：

我终于找到了一个很好的解决方案，目前效果很好！

我设置：

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

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

【讨论】：

【解决方案2】：

~~嗯，你所说的时间似乎确实存在，只是没有明确表示。~~

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

~~initialDelaySeconds + period * (failureTreshold - 1)~~

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

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

【讨论】：

好吧，问题在于描述上写着“在成功后，探针被视为失败的最小连续失败。默认为 3。最小值为 1。”所以它应该在 failureTreshold 成功之前成功一次！
你说得对，我错过了。我认为您现在唯一的选择是增加 initialDelaySeconds 。您可以在github.com/kubernetes/kubernetes/issues 中提交功能请求，解释您的用例。
或者（它很hacky，但可能会起作用）您可以创建一个在第一次运行时会成功的活性探针（也许在bash中使用条件设置env变量？），但会运行您的正常活性在随后的运行中进行探测。这样，您将拥有“成功”的 pod，并且您将能够使用 period 和 failureTreshold。