0

我使用 8888 进行活性和就绪探测，8887 用于正常 HTTP 请求，就绪探测失败并且 pod 处于 0/1，未就绪状态。但是我仍然看到 pod 正在处理正常的 POST 请求。这是预期的吗。是否应该在同一个端口上接收健康探测和正常请求？

4

2 回答 2

0

Liveness 和 Readyness 探针有不同的用途。简而言之，liveness probe 控制着 Kubernetes 是否会重启 Pod。但是就绪探针控制一个 pod 是否包含在服务的端点中。除非 Pod 通过就绪探测表明它已准备就绪，否则它不应通过服务接收流量。这并不意味着它不能发送请求，它只是意味着它不会通过服务发送流量。所以在你的情况下，问题是，这些 POST 请求来自哪里。

于 2020-07-28T06:51:04.737 回答
0

@pst 和 @Harsh 是对的，但我想稍微扩展一下。

正如官方文档所说：

如果您希望仅在探测成功时才开始向 Pod 发送流量，请指定就绪探测。在这种情况下，readiness probe 可能和 liveness probe 一样，但是 spec 中 readiness probe 的存在意味着 Pod 会在不接收任何流量的情况下启动，只有在探测成功后才开始接收流量。

和：

kubelet 使用就绪探测来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备好时，就认为 Pod 准备好了。此信号的一种用途是控制哪些 Pod 用作服务的后端。当 Pod 未准备好时，它会从服务负载均衡器中移除。

回答你的问题：

因此，如果就绪探测失败，我还应该期待 8887 上的流量吗？

不，如果就绪探测失败，Pod 不应开始接收流量。

它也可能取决于您的应用程序。通过使用就绪探测，Kubernetes 会等到应用程序完全启动后才允许服务将流量发送到新副本。

此外，确保您的探针配置正确非常重要：

探针有许多字段，您可以使用它们来更精确地控制活动性和就绪性检查的行为：

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

  • periodSeconds：执行探测的频率（以秒为单位）。默认为 10 秒。最小值为 1。

  • timeoutSeconds: 探测超时的秒数。默认为 1 秒。最小值为 1。

  • successThreshold：探测失败后被视为成功的最小连续成功次数。默认为 1。活性必须为 1。最小值为 1。

  • failureThreshold：当一次探测失败时，Kubernetes 会尝试 failureThreshold 次才放弃。在 liveness probe 的情况下放弃意味着重新启动容器。在就绪探测的情况下，Pod 将被标记为未就绪。默认为 3。最小值为 1。

如果你想扩展关于 liveness、readiness 和 startup probes 的知识，请参考官方文档。您将在那里缠绕一些可以与您的设置进行比较的示例，以查看您是否理解并正确配置了它。

于 2020-07-28T12:48:42.240 回答