无法理解“何时使用kubernetes的启动程序”中的死锁场景？

Question

在库伯奈特的官方文档中，我读到了这个页面(关于container probes和为什么我们应该使用startup-probe)。

你应该什么时候使用启动探针？，他们说：

如果容器通常在initialDelaySeconds + failureThreshold × periodSeconds之外启动，则应该指定一个启动探针，它检查与活动探测相同的端点。periodSeconds的缺省值是10 s。然后，您应该将其failureThreshold设置得足够高，允许容器启动，而不更改活动探测的默认值。这有助于防止死锁。

我理解了为什么我们需要使用startup probe的全部原因(我理解我们需要使用startup probe的原因是:对于那些容器需要很长时间才能投入使用的Pods来说，启动探测是有用的。正如我们所知道的，如果提供了启动探测，那么所有其他探测都会被禁用，直到它成功。因此，如果容器启动时间较长，那么我们将使用startup probe，以便在容器启动之前，其他两个探测仍然是禁用的)。

但在这里，我没有得到deadlock的场景，deadlock在哪里发生，为什么会发生？有人能解释一下他们正在谈论的deadlock场景吗？我们用startup probe来防止哪一个startup probe？

Answer 1

startup probe被设计为只在容器启动后执行一次。

Readiness probe和liveness Probe不仅执行启动。

如果启动探针超过配置的failureThreshold而没有成功，容器就会被杀死并重新启动，这取决于容器的restartPolicy，这种行为类似于活性探测。

负载均衡器可以使用准备状态探针来确定何时可以发送流量。

启动探针用例

使用startup probe的示例原因是：

您的应用程序已经启动了很长时间。您可以为readiness probe和liveness probe增加readiness probe和liveness probe，但不知道容器什么时候准备好了，因为没有在delay时间执行这些探测。

因此，startup probe通常与readines和liveness探针一起使用。它一直执行到容器准备就绪为止(直到startup probe返回Success状态)，因此不再需要延迟。

外部依赖

假设您的应用程序启动了1-3分钟(它可能取决于外部API、资源、慢网络等)。您可以将delays设置为190秒，但如果容器在60秒后准备就绪，则至少可以浪费2分钟。为了解决这个问题，设计了startup probe。

首次初始化

有时，您必须处理遗留应用程序，这些应用程序在第一次初始化时可能需要额外启动时间。在这种情况下，很难设置活性探测参数，而不影响对触发这种探测的死锁的快速响应。诀窍是使用相同的命令HTTP或TCP设置一个启动探测，其failureThreshold * periodSeconds足够长，足以覆盖更糟糕的启动时间。

你的问题

当容器尚未准备好但liveness probe正在执行，并且由于延迟时间太短而超过failure treshold时，就会出现死锁。在这种情况下，容器一直在重新启动。为了防止出现这种情况，您应该使用startup probe并将阈值设置得足够高。

Answer 2

我现在完全清楚我的问题。因此，我想解释一下我所理解的全部情况(希望它将来能对其他人有所帮助)。丹尼尔的回答是正确的，但我只想更全面地解释一下。

对这些术语的解释：

1. initialDelaySeconds：容器在计划探测之前启动的秒数，这意味着在此之后，定义的探测将调度。
2. failureThreshold：在激活探测重新启动容器之前允许探测失败的次数(或者在准备就绪的情况下，探针将吊舱标记为不可用)。
3. periodSeconds：这意味着在每个periodSeconds中，kubelet将执行预定的探测。
4. initialDelaySeconds + failureThreshold × periodSeconds：总时间，在此之后，预定的探测将根据它们的特性采取行动(活性探测重新启动容器，或者在准备就绪的情况下，探针将吊舱标记为不可用)。

从@Daniel注释中，也要记住，所有的探测都将failureThreshold和periodSeconds分开。因此，对于liveness probe来说，这些值很小，因为它不能正常工作，所以杀死容器的速度很小，因为starup probe值可能更高，可以等待足够长的时间来启动。

僵局是如何发生的

现在，如果没有使用startup probe，并且容器启动所需的时间超过了总(initialDelaySeconds + failureThreshold × periodSeconds)时间，那么只要initialDelaySeconds + failureThreshold × periodSeconds时间过去，liveness probe就会通过kubelet重新启动容器，因为如果活性探测失败，kubelet将杀死容器，容器将受到其重新启动策略的约束。

在重新启动容器时，同样的场景会一次又一次地发生，并且容器不会每次都启动。这里出现了僵局。

因此，出现死锁是因为容器启动所用的时间比initialDelaySeconds + failureThreshold × periodSeconds时间长，而且这里没有使用startup probe。

防止死锁

现在，为了防止死锁，我们可以做两件事：

1. 我们可以给出较高的liveness interval，但是由于容器所能占用的时间并不固定，这就是为什么这种方法不是更好的方法的原因。
2. 如我们所知，我们可以使用startup probe，如果提供了启动探针，所有其他探测都会被禁用，直到它成功为止。因此，如果我们使用startup probe，我们就不需要讨论以前发生的死锁了。

现在只剩下另一件事了，那就是我们需要给出高failureThreshold，因为如果连接者启动的时间比initialDelaySeconds + failureThreshold × periodSeconds时间长，那么startup probe也可能失败(这里需要明确的一点是，initialDelaySeconds + failureThreshold × periodSeconds是通用公式，并分别为所有探针计算)。因此，我们还需要在使用failureThreshold时设置较高的startup probe。这样可以完全解决deadlock问题，也可以保证容器有足够的启动时间。