kubernetes准备就绪检查应该做什么

我知道如何在kubernetes中设置就绪探测，但是在调用就绪探测时，是否有关于微服务应该实际检查什么的最佳实践？两个具体例子：

面向数据库的微服务，如果没有正常的数据库连接，几乎所有功能都无法工作。在这里，我认为ping数据库是合理的，如果ping失败，就不能通过就绪性检查。这是推荐的吗

使用N个其他微服务的微服务，但如果无法连接到任何一个微服务，大部分功能仍然可以工作。在这里，我认为检查与支持服务的连接是不明智的。在这种情况下，假设没有广泛的“启动”或“预热”处理，活跃度和准备度是等效的。对吗

---

谢谢你

不，我认为没有关于准备就绪探测的最佳实践

这完全取决于应用程序和您希望发生的事情

在这里，我认为ping数据库是合理的，如果ping失败，就不能通过就绪性检查

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

您必须问问自己，这是否是您想要/期望的行为，或者当db出现故障时，Ready probe不发生故障可能会更方便，在这种情况下，microservice仍将处理流量，并且能够向客户返回错误消息，告知他该问题

在这种情况下，即使是简单的503也会更好。获取实际错误消息比获取连接超时更能说明实际问题

---

[…]但是，如果无法连接到任何一个，大多数功能仍然可以工作。在这里，我认为检查与支持服务的连接是不明智的。在这种情况下，假设没有广泛的“启动”或“预热”处理，活跃度和准备度是等效的

这取决于用例。在应用程序代码中，您可以更快地对备份服务出现的问题做出反应，我会尽可能地使用这种方法，并且只在无法以不同方式处理备份服务时使用准备检查备份服务

---

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

这取决于你定义什么是“仍然运行”和“能够处理流量”

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