我了解如何在 kubernetes 中设置就绪探针，但是关于调用就绪探针时微服务应实际检查的内容是否有任何最佳实践？两个具体例子：
谢谢
不，我认为没有准备就绪探测的最佳实践。
这一切都取决于应用程序和你期望发生的事情。
在这里，我认为 ping 数据库是合理的，如果 ping 失败，则准备检查失败
我将尝试对此发表评论。假设您有一些后端微服务（使用多个副本进行部署）并且它正在与数据库通信。当 db 发生故障时（假设没有复制或一些严重的 db 停机时间），您的 pod 副本的就绪探测开始失败，并且 pod 的端点将从服务中删除。现在当客户端尝试访问服务时，将导致连接超时，因为没有服务来处理请求。
您必须问自己这是否是您想要/期望的行为，或者当数据库失败时，准备探测不会失败会更方便，在这种情况下微服务仍会处理流量，并且能够返回错误给客户的消息，告知他问题。
在这种情况下，即使是简单的 503 也会好得多。获取实际错误消息比获取连接超时更能告诉我有关实际问题的信息。
[...] 但是如果无法连接到任何人，大多数功能仍然可以正常工作。在这里，我认为检查与支持服务的连接是不明智的。在这种情况下，假设没有广泛的“启动”或“热身”处理，活跃度和就绪度是等价的。
这取决于用例。在应用程序代码中，您可以更快地对支持服务发生的问题做出反应，我会尽可能使用这种方法，并且仅在无法以不同方式处理时才使用准备检查支持服务。
所以对我来说，活性探针回答了这个问题：“这个应用程序还在运行吗？” 并且准备问题回答了这个问题：“这个应用程序准备好处理/能够处理流量了吗？”
您可以定义“仍在运行”和“能够处理流量”的含义。
但通常如果应用程序正在运行，它也能够处理流量，因此在这种情况下，活跃度和就绪度确实是相等的。