kubernetes - kubernetes 就绪检查应该检查什么

Question

我了解如何在 kubernetes 中设置就绪探测器，但是是否有任何关于在调用就绪探测器时微服务应实际检查哪些内容的最佳实践？两个具体例子:

1. 一个面向数据库的微服务，如果没有有效的数据库连接，几乎所有功能都将无法运行。在这里，我认为对数据库执行 ping 操作是合理的，如果 ping 失败，就绪检查将失败。这是推荐的吗？
2. 一种使用 N 个其他微服务的微服务，但无法连接到任何一个微服务时，大部分功能仍然可以正常工作。在这里，我认为检查与支持服务的连接是不明智的。在这种情况下，假设没有大量的“引导”或“预热”处理，活跃性和就绪性是等价的。正确吗？

谢谢

Answer 1

不，我不认为就绪探测有最佳实践。

这完全取决于应用和您期望发生的事情。

Here I think pinging the db would be reasonable, failing the readiness check if ping fails

我会尝试对此发表评论。假设您有一些后端微服务(使用多个副本部署)并且它正在与数据库通信。当数据库失败时(假设没有复制或一些严重的数据库停机)，您的 Pod 副本的就绪探测开始失败，并且 Pod 的端点将从服务中删除。现在，当客户端尝试访问该服务时，将导致连接超时，因为没有服务可以处理该请求。

你必须问问自己这是否是你想要/期望的行为，或者当数据库失败时准备就绪探测不会失败会更方便，微服务在这种情况下仍会处理流量，并且能够向客户返回一条错误消息，告知他这个问题。

在这种情况下，即使是简单的 503 也会好得多。收到实际错误消息比收到连接超时更能告诉我实际问题。

---

[...] but where failure to connect to any one would still allow for a majority of the functionality to work. Here I think checking for connectivity to the backing services is ill advised. In this case, assuming there is no extensive "boot" or "warm up" processing, liveness and readiness are equivalent.

这取决于用例。在应用程序代码中，您可以更快地对支持服务发生的问题使用react，我会尽可能使用这种方法，并且仅在无法以不同方式处理时才使用就绪状态来检查支持服务。

---

所以对我来说，liveness probe 回答了这个问题:“这个应用程序还在运行吗？”准备问题回答了这个问题:“这个应用程序准备好处理/能够处理流量了吗？”

由您来定义“仍在运行”和“能够处理流量”是什么意思。

但通常如果应用程序正在运行，它也能够处理流量，因此在这种情况下，活跃度和就绪度确实是相等的。