Kubernetes 探测配置中的 periodSeconds 是从上次探测时间还是上次响应/失败时间开始计算的？答案

【问题标题】：Does periodSeconds in Kubernetes probe configuration count from the last probe time or the last response/failure time?Kubernetes 探测配置中的 periodSeconds 是从上次探测时间还是上次响应/失败时间开始计算的？
【发布时间】：2020-10-06 16:42:27
【问题描述】：

例如，假设我有一个 Pod 对其活性探测执行 GET 请求，超时时间为 5 秒，周期为 10 秒。这些时间线中的哪一个代表了探测的时间？

自上次探测模式：

0s: liveness probe initiated
5s: liveness probe times out
10s: liveness probe initiated again because 10 seconds have elapsed since the start of the last probe

或自超时模式：

0s: liveness probe initiated
5s: liveness probe times out
15s: 10 seconds have elapsed since the timeout occurred, so the probe fires again

在前者中，探测之间总是有 10 秒的间隔，但在后者中，探测之间的间隔可能在 10 到 15 秒之间，具体取决于请求返回的速度。 Kubernetes 使用哪种方法？

【问题讨论】：

标签： kubernetes

【解决方案1】：

Kubernetes livenessProbe 是这样工作的：

periodSeconds 从最后一次发送探测的时间开始计算
永远不会有两个探针同时运行，如果探针尚未超时，则等待新的探针

因此，在您的情况下（timeoutSeconds=5、periodSeconds=10），探针将如下所示：

0s: liveness probe initiated
5s: liveness probe times out
10s: liveness probe initiated again because 10 seconds have elapsed since the start of the last probe

如果您有相反的情况（timeoutSeconds=10、periodSeconds=5），那么探针将如下所示：

0s: liveness probe initiated
10s: liveness probe times out
10s: liveness probe initiated again

【讨论】：

【解决方案2】：

根据 kubernetes 文档 -

kubelet 在容器启动后开始执行健康检查 'x' 秒（即 period ）。这意味着探测已经过去，一旦你从 api 调用本身获得成功响应，周期就会开始，最终这意味着容器已经启动（前提是探测中提到的针对端点的 HTTP 方法已经正确编写）。

对于失败的情况，很明显，直到超时它会等待响应来标记它的健康或不健康，然后它会尝试同样的事情3次，如果探测失败，最终会重新启动容器。

【讨论】：