无法理解“何时应该使用kubernetes的启动探针"中的死锁情况? [英] Cannot understand the deadlock scenario in `When should you use a startup probe` of kubernetes?

问题描述

在kubernetes官方文档中，我正在阅读此页面(关于container probes以及为什么我们应该使用startup-probe)
何时应-you-use-a-startup探针，它们表示如下:

In kubernetes official docs, I was reading this page (about the container probes and why we should use startup-probe)
when-should-you-use-a-startup probe, they stated like:

如果您的容器通常从多个initialDelaySeconds + failureThreshold × periodSeconds开始，则应指定一个启动探针，该探针检查与活动探针相同的终结点. periodSeconds的默认值为10s.然后，应将其failureThreshold设置得足够高，以允许容器启动，而不更改活动性探针的默认值.这有助于防止死锁.

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的原因是:启动探针对于具有需要很长时间才能进入的容器的Pod很有用我们知道，如果提供了启动探针，则所有其他探针都将被禁用，直到成功为止，因此，如果容器需要更长的时间才能启动，那么我们将使用startup probe，以便在容器启动之前，其余两个探针仍然保留禁用).

I understood the whole things that why we need to use startup probe (what i understood that why we need to use startup probe is that: Startup probes are useful for Pods that have containers that take a long time to come into service. As we know, all other probes are disabled if a startup probe is provided, until it succeeds. So if the container takes longer time to start up then we will use startup probe so that until the container start the other two probes remain disabled).

但是在这里我没有得到deadlock的情况，deadlock发生在哪里以及为什么发生?谁能解释他们所谈论的deadlock情景?通过使用startup probe我们可以防止哪个deadlock?

But here I did not get the scenario of deadlock, where and why the deadlock is happening? can anyone explain the scenario of the deadlock that they are talking about? which deadlock are we preventing by using startup probe?

推荐答案

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

The startup probe is designed to be performed only once after container start.

Readiness probe和liveness Probe不仅是在启动时执行的.

Readiness probe and liveness Probe are performed not only the startup.

如果启动探针超过配置的failureThreshold而不成功，则容器将被挂起并重新启动，并受pod的restartPolicy约束，该行为类似于活动性探针.

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.

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

Readiness probe may be used by load balancer to determine when it can send traffic.

使用startup probe的示例原因是:

您的应用程序启动了很长时间.您可以增加readiness probe和liveness probe的delays，但您不知道容器何时准备就绪，因为在delay时间内未执行这些探测.

Your application is starting for a long time. You can increase delays for readiness probe and liveness probe but you do not know when your container is ready because those probes are not performed for delay time.

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

So startup probe is used commonly with readines and liveness probes. It is performed until your container is ready(till your startup probe returns the Success status), so you do not need delays anymore.

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

Let's say your application is starting for 1-3 minutes(it may depend on external API, resources, slow network etc.). You can put delays to 190 seconds, but you can waste at least 2 minutes if your container is ready after 60 seconds. To solve that issue startup probe was designed.

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

Sometimes, you have to deal with legacy applications that might require an additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The trick is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worse case startup time.

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

The deadlock is situation, when your container is not ready but liveness probe is performing and it exceed failure treshold, because of too short delay time. In this situation your container keeps restarting. To prevent that you should use startup probe and put your threshold high enough.

这篇关于无法理解“何时应该使用kubernetes的启动探针"中的死锁情况?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！