我了解如何在kubernetes中设置就绪探针，但是关于调用就绪探针时微服务应实际检查的内容是否有最佳实践？两个具体示例：
谢谢
答案 0 :(得分：0)
不，我认为没有准备就绪探针的最佳实践。
这一切都取决于应用程序和您将要发生的事情。
在这里，我认为ping数据库是合理的，如果ping失败，则无法通过就绪检查
我将尝试对此发表评论。假设您有一些后端微服务（与服务器副本一起部署），并且它正在与数据库通信。当数据库失败（假设没有复制或某些严重的数据库停机时间）时，您的Pod副本的准备就绪探针开始失败，并且Pod的终结点将从服务中删除。现在，当客户端尝试访问服务时，由于没有服务可以处理请求，因此将导致连接超时。
您必须问问自己这是否是您想要/期望的行为，或者如果在数据库发生故障时就绪探针不会失败，这将更方便，在这种情况下微服务仍将处理流量，并且能够向客户返回错误消息，告知客户有关该问题的信息。
在这种情况下，即使是简单的503也会更好。收到实际错误消息比得到连接超时更能告诉我有关实际问题的信息。
[...]，但是在无法连接到任何人的情况下，大多数功能仍然可以使用。在这里，我认为不建议检查与支持服务的连接。在这种情况下，假设没有大量的“启动”或“热身”处理，则活动性和就绪性是等效的。
这取决于用例。在应用程序代码中，您可以对支持服务出现的问题更快地做出反应，并且我会尽可能使用这种方法，并且只有在无法不同地处理支持服务时，才准备使用它来检查支持服务。
因此，对我而言，活力探针回答了以下问题：“此应用程序仍在运行吗？” readines会回答以下问题：“此应用程序已准备好处理/能够处理流量吗？”
由您决定“仍然运行”和“能够处理流量”是什么意思。
但是通常情况下，如果应用程序正在运行，它也能够处理流量，因此在这种情况下，活跃性和就绪性是相等的。