无法理解kubernetes《何时应该使用启动探针》中的死锁场景？

Question

在 kubernetes 官方文档中，我正在阅读此页面（关于container probes以及为什么我们应该使用startup-probe）
\nwhen -should-you-use-a-startupprobe，他们说：

\n

\n

如果您的容器通常启动时间超过initialDelaySeconds + failureThreshold \xc3\x97 periodSeconds，您应该指定一个启动探针来检查与活动探针相同的端点。默认值为periodSeconds10 秒。然后，您应该将其设置得failureThreshold足够高以允许容器启动，而无需更改活性探针的默认值。这有助于防止死锁。

\n

\n

我理解我们需要使用的全部内容startup probe（我理解我们需要使用的原因startup probe是：启动探针对于容器需要很长时间才能投入使用的 Pod 很有用。据我们所知，所有其他探针如果提供了启动探针，则将被禁用，直到成功为止。因此，如果容器需要更长的时间来启动，那么我们将使用startup probe这样的方式，以便在容器启动之前，其他两个探针保持禁用状态。

\n

但在这里我没有得到这个场景deadlock，在哪里以及为什么deadlock发生？deadlock谁能解释一下他们正在谈论的场景？deadlock我们通过使用来预防哪些startup probe？

\n

Answer 1

该startup probe操作被设计为在容器启动后仅执行一次。

Readiness probe并且liveness Probe不仅执行启动。

如果启动探测超过配置的 failureThreshold 但没有成功，容器将被终止并重新启动，并受 pod 的 restartPolicy 约束，该行为类似于活性探测。

负载均衡器可以使用就绪探测来确定何时可以发送流量。

启动探针用例

使用示例的原因startup probe是：

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

因此通常与和探头startup probe一起使用。它会一直执行到您的容器准备就绪（直到您返回状态），因此您不再需要延迟。readineslivenessstartup probeSuccess

外部依赖

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

第一次初始化

有时，您必须处理旧应用程序，这些应用程序在首次初始化时可能需要额外的启动时间。在这种情况下，在不影响对引发此类探测的死锁的快速响应的情况下设置活性探测参数可能会很棘手。诀窍是使用相同的命令、HTTP 或 TCP 检查来设置启动探测，并使用足够长的 failureThreshold * periodSeconds 来覆盖最坏情况下的启动时间。

你的问题

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