为什么准备调查开始晚了？

Question

我有一个带有探针的吊舱，下面是定义的探针：

Liveness:   exec [/liveness-probe-script] delay=0s timeout=10s period=30s success=1 #failure=3
Readiness:  exec [/readiness-probe-script] delay=0s timeout=10s period=30s success=1 #failure=3
Startup:    exec [/startup-probe-script] delay=0s timeout=140s period=10s success=1 #failure=1

我在脚本中添加了一些日志：

startup probe starting at: 14:57:34
finished at: 14:57:37

readiness probe starting at: 14:57:47
finished at: 14:57:47

liveness probe starting at: 14:57:48
finished at: 14:57:48

如您所见，准备就绪和活性探测在启动探针已经完成后启动10s。

能做点什么吗？这是正常行为吗？

编辑：

为了澄清这一点，我了解到，如果配置了启动探针+ initialDelaySeconds，激活/就绪探测将在启动探针+之后开始。我的问题是，为什么在14:57:37结束的启动探针与14:57:47开始的准备状态探针之间存在10s的差距，有时甚至更小，而没有任何延迟配置？为什么准备好的探测器不立即在启动探针后14:57:38启动？

Answer 1

按定义、就绪和活性探测是在容器启动后进行的。这意味着在启动探针完成之后。

在医生开始时：

kubelet使用启动探测来了解容器应用程序何时启动。如果配置了这样的探测，将禁用活性检查和就绪检查，直到成功为止，确保这些探测不会干扰应用程序启动。

然后在initialDelaySeconds参数定义中：

initialDelaySeconds：容器启动后的秒数，在启动活动或就绪探测之前启动。默认为0秒。最小值为0。

如果您想避免这种行为，如果您的用例不需要，可以通过不使用startup probe，的来做到这一点。

Answer 2

我试着复制你的问题。我在is K8S 1.23.3中使用了OpenShift 4.10.3。我构建了一个简单的服务，它只响应几个简单的端点，这些端点充当探测端点。

我的吊舱看起来是这样的：

    Liveness:     http-get http://:8080/livez delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:    http-get http://:8080/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Startup:      http-get http://:8080/startz delay=1s timeout=1s period=1s #success=1 #failure=30

请注意，与您不同，我在启动时添加了1s延迟，并将启动期更改为1s。对于所有探测，我的超时时间也是1s，这是默认的。稍后再谈这件事。

我的应用程序日志看起来像

2022-03-23 16:23:24,008 INFO (executor-thread-0) Startup probe
2022-03-23 16:23:24,222 INFO (executor-thread-0) Ready probe
2022-03-23 16:23:31,860 INFO  (executor-thread-0) Liveness probe

所以我们看到，我的准备状态探测器在启动探测器之后大约200毫秒。我在这里做了一些变化，但总是在秒以下。

我确实尝试过使用相同的参数，但是0秒延迟几乎总是导致连接第一次被拒绝失败。因为即使它是一个很小的服务，如果立即调用启动探针，它仍然没有足够快地创建。这导致了10秒的退步。这就是为什么我把它改为1秒的启动探针和1秒的周期。

所以，要回答你的直接问题，这是不正常的。但是你并没有真正显示你的吊舱信息(比如事件)。也没有列出您已经尝试过解决此问题的方法。所以我不确定我能告诉你是什么问题。

我有几种可能性。

1. 您的开始探测失败了，在准备探测之前所看到的10s延迟与探测的超时延迟有关。您的应用程序日志对此有争议，但我发现10 s延迟与所有探测都有10 s超时这一事实太巧合了。我会得到事件的吊舱，看看你是否看到探测失败。在一般原则下，我也会将超时更改为1，除非您有理由不这样做。
2. 作为一个相关的问题，您已经将您的问题定义为exec脚本，而不是直接定义为K8S中的http-get。这让我怀疑剧本里发生了什么奇怪的事。再说一次，因为超时似乎是巧合。我会尝试直接调用HTTP端点，看看这是否解决了问题。
3. 你说的差距是“有时更多，有时更少”。我认为问题可能只是一个重载/不健康的kubelet，只是没有及时地调度探测。似乎不太可能，因为如果您有10s的kubelet延迟，那么您会遇到更大的问题，但是获取kubelet日志可能会有帮助。

无论如何，我肯定会考虑调整你的探测超时和延迟。我还会考虑删除启动探针。启动探测实际上是为那些奇怪的启动状态和漫长的初始化阶段的遗留应用程序设计的。对于您的应用程序，是否真的存在其他所有探测都没有意义的启动状态？