kubernetes - 看不懂kubernetes `When should you use a startup probe`的死锁场景？

Question

在 kubernetes 官方文档中，我正在阅读此页面(关于 container probe 以及为什么我们应该使用 startup-probe)
when-should-you-use-a-startup probe ，他们说:

If your container usually starts in more than initialDelaySeconds + failureThreshold × periodSeconds, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for periodSeconds is 10s. You should then set its failureThreshold high enough to allow the container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.

我理解了为什么我们需要使用 startup probe 的全部内容(我理解为什么我们需要使用 startup probe 是:Startup probes are useful for具有需要很长时间才能投入使用的容器的 Pod。正如我们所知，如果提供了启动探测，所有其他探测都会被禁用，直到它成功。因此，如果容器需要更长的时间才能启动，那么我们将使用 startup probe 以便在容器启动之前，其他两个探测器保持禁用状态)。

但是这里我没有得到deadlock的场景，deadlock发生在什么地方，为什么发生？任何人都可以解释他们正在谈论的 deadlock 场景吗？我们通过使用 startup probe 防止了哪些死锁？

Answer 1

启动探测 被设计为在容器启动后仅执行一次。

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

If a startup probe exceeds the configured failureThreshold without succeeding, the container is killed and restarted, subject to the pod's restartPolicy, a behavior analogous to the liveness probe.

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

启动探测用例

使用 startup probe 的示例原因是:

您的应用程序启动时间很长。您可以增加 readiness probe 和 liveness probe 的 delays，但您不知道容器何时准备就绪，因为这些探测不会针对 执行>延迟时间。

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

外部依赖

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

第一次初始化

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

你的问题

死锁是这样的情况，当你的容器还没有准备好但是 liveness probe 正在执行并且它超过了 failure treshold，因为延迟时间太短了。在这种情况下，您的容器会不断重启。为防止出现这种情况，您应该使用 startup probe 并将阈值设置得足够高。