k8s - livenessProbe 与 readinessProbe

Question

考虑一个通过 http 端点 /health 在端口 80 设置运行状况检查的 pod，它需要将近 60 秒才能真正准备好并为流量提供服务。

readinessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 60
livenessProbe:
  httpGet:
    path: /health
    port: 80

问题：

• 我的上述配置是否符合给定的要求？
• 是否只有在 pod 准备就绪后，活性探针才开始工作？换句话说，我假设一旦 POD 准备就绪，就绪探测作业就完成了。之后 livenessProbe 负责健康检查。在这种情况下，我可以忽略 initialDelaySeconds 的 livenessProbe。如果它们是独立的，那么当 pod 本身还没有准备好时，进行 livenessProbe 检查有什么意义！ ?
• 检查此documentation。他们的意思是什么

如果您希望您的 Container 能够自行关闭 维护，您可以指定检查端点的就绪探针 特定于与 liveness 探测不同的就绪状态。

我假设，只有在 livenessProbe 失败时，正在运行的 pod 才会自行关闭。不是readinessProbe。医生说另一种方式。

澄清！

Answer 1

活性探针用于检查容器是否已启动并处于活动状态。如果不是这样，kubernetes 最终会重启容器。

反过来，就绪探针也会检查依赖关系，例如数据库连接或容器依赖的其他服务来完成它的工作。作为开发人员，您必须在这里投入更多的时间来实现，而不仅仅是活性探测。您必须公开一个端点，该端点也在查询时检查提到的依赖项。

您当前的配置使用了一个健康端点，该端点通常由活性探针使用。它可能不会检查您的服务是否真的准备好接受流量。

Kubernetes 依赖于就绪探测。在滚动更新期间，它将保持旧容器启动并运行，直到新服务声明它已准备好接受流量。因此，必须正确实施就绪探测。

Answer 2

我从第二个问题开始回答。第二个问题是：

liveness probe 是否只有在 pod 准备就绪后才开始工作？ 换句话说，我假设一旦 POD 完成就绪探测工作 准备好了。之后 livenessProbe 负责健康检查。

我们最初的理解是，liveness probe 会在 readiness probe 成功后开始检查，但 事实并非如此。它已经为这个挑战打开了一个问题。你可以查看here。然后通过添加startup probes.解决了这个问题

总结一下：

• livenessProbe

livenessProbe： 指示 Container 是否正在运行。如果 liveness 探测失败，kubelet 杀死了 Container，并且 容器受其重启策略的约束。如果容器不 提供一个活性探针，the default state is Success.

• readinessProbe

readinessProbe： 指示容器是否准备好为请求提供服务。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是失败。如果 Container 没有提供就绪探测，the default state is Success.

• startupProbe

startupProbe：指示Container内的应用程序是否启动。 如果提供了启动探针，则所有其他探针都将被禁用，直到它成功。 如果启动探针失败，kubelet 会杀死 Container，并且 Container 会受到其重启策略的约束。如果 Container 不提供启动探测，the default state is Success

查找here。

Answer 3

readiness 探测和 liveness 探测似乎具有相同的行为。他们进行相同类型的检查。但是他们在失败的情况下采取的行动是不同的。

Readiness Probe 会关闭来自服务的流量。这样服务可以始终将请求发送到健康的 pod，而 liveness 探针会在发生故障时重新启动 pod。它对服务没有任何作用。如果处于“available”状态，Service 会继续像往常一样向 Pod 发送请求。

建议两个探头都用！！

查看here 以获取带有代码示例的详细说明。

Answer 4

Kubernetes 平台具有验证容器应用程序的功能，称为运行状况检查。 Liveness 是可用性证明，readness 是 Pod 准备就绪可以使用的证明。 这些功能旨在通过在需要时重新启动来防止服务停机和图像不一致。 Kubernetes 使用 liveness 知道何时重启容器，因此它可以解决大多数问题。 Kubernetes 使用 readness 来了解容器何时可以接受请求。当所有容器都准备好时，Pod 被认为是准备好了。因此，当 Pod 初始化时间过长（通过缓存挂载、DB 模式等）时，建议增加 initialDelaySeconds。

Answer 5

我会把它作为评论发布，但它太长了，所以让我们把它作为一个完整的答案。

我的上述配置是否适合给定的要求？

恕我直言，不，您缺少 initialDelaySeconds 的探针，并且 liveness 和 rediness 可能不应该调用同一个端点。我会使用@fgul 的建议表

是否只有在 pod 准备好后才开始工作？ 换句话说，我假设一旦 POD 完成就绪探测工作 准备好了。之后 livenessProbe 负责健康检查。在这个 在这种情况下，我可以忽略 livenessProbe 的 initialDelaySeconds。如果他们 是独立的，什么时候做 livenessProbe check 有什么意义 吊舱本身还没有准备好！ ?

我认为你在考虑startupProbe，@fgul 再次描述了做什么，所以我重复没有意义。

我假设，只有在 livenessProbe 失败。不是readinessProbe。医生说另一种方式。

pod 只能基于livenessProbe 重启，redinessProbe 不能重启。

在将 rediness 探针与外部服务绑定之前我会三思而后行（如 @randy 建议的那样活着），尤其是在高负载服务中：

假设您已经定义了一个包含大量 pod 的部署，这些 pod 连接到数据库并处理大量请求。 现在数据库宕机了。 rediness 探针也在检查数据库连接，并将所有 pod 标记为“停止服务”。 现在数据库上升了。 豆荚红度探测将开始通过，但不会立即在所有豆荚上立即通过 - 豆荚将一个接一个地标记为“就绪”。 但这可能太慢了——第二个第一个 pod 将被标记为就绪，所有流量都将单独发送到这个 pod。最终可能会导致“唤醒”的 pod 一个接一个地被流量杀死。

对于这种情况，我会说 rediness pod 应该只检查 pod 内部的东西，而不关心外部服务。 kubernetes 端点将返回一个错误，并且客户端可能支持失败的服务（称为“为失败而设计”），或者负载均衡器/入口可以覆盖它。

Answer 6

我将通过几个简单的点来说明它们之间的区别：

livenessProbe

 livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 用于指示容器是否已启动且是否处于活动状态，即可用的证明。
• 在给定的示例中，如果请求失败，它将重新启动容器。
• 如果未提供，则默认状态为成功。

readinessProbe

 readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 它用于指示容器是否已准备好为流量提供服务，即准备好使用的证明。
• 它会检查依赖项，例如数据库连接或您的容器为完成其工​​作所依赖的其他服务。
• 在给定的示例中，在请求返回 Success 之前，它不会提供任何流量（通过从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址）。
• Kubernetes 在滚动更新期间依赖就绪探测，它使旧容器保持正常运行，直到新服务声明它已准备好接收流量。
• 如果未提供，则默认状态为成功。

---

总结

Liveness Probes：用于检查容器是否可用且处于活动状态。

Readiness Probes：用于检查应用程序是否已准备好使用并为流量提供服务。

Answer 7

活性探针是一种相对专业的工具，您可能根本不需要。然而，他们完全独立运行 AFAIK。