我正在开发一个应用程序，我可以看到它正在执行多项运行状况检查？
当我查看集群日志时，我意识到我的服务在数据库检查失败时只会抛出 500 并关闭。我在这里无法理解的是，如果数据库关闭或另一个 API 关闭，如果我没有准备就绪探测器，那么我的容器无论如何都会关闭。此外，我会看到我的应用程序确实抛出了一些 500，因为 DB 或其他服务已关闭。
无论如何，我的容器的就绪探针下降有什么好处？我的另一个问题是 Healthcheck 是不是只有在我将服务部署到集群时才应该考虑？如果不是集群微服务环境，是否会增加/减少执行健康检查的好处？
答案 0 :(得分：2)
就绪探针在几个地方使用。一个重要的问题是未就绪的 pod 从引用它们的所有服务中删除。它们对于 Deployments/StatefulSet 上的滚动更新也很重要，因为在新 pod 达到就绪状态之前滚动不会继续。一般来说，用于就绪探测的检查应该只检查当前服务。所以它不应该接触数据库。有时这很难实现，并且确实使它们变得不那么有用。但是检查每个 Pod 的内容，例如 Web 服务器正在侦听端口并可以返回 HTTP 响应。
答案 1 :(得分：2)
Kubernetes 使用三种类型的探测器来检查 Pod 的健康状况：
Liveness：告诉 Kubernetes 容器内部出现问题，最好重新启动它，看看 Kubernetes 是否可以解决错误。Readiness：告诉 Kubernetes Pod 已准备好接收流量。有时发生的事情不会使 Pod 完全丧失能力，但无法满足客户的要求。例如：失去与数据库的连接或第三方服务失败。在这种情况下，我们不希望 Kubernetes 重置 Pod，但我们也不希望它向它发送无法满足的流量。当 Readiness 探测失败时，Kubernetes 从服务中删除 Pod 并停止与 Pod 的通信。错误解决后，Kubernetes 可以将其添加回来。Startup：在 Pod 已启动并准备好接收流量时通知 Kubernetes。这些探针对于需要一段时间才能开始的应用程序特别有用。当 Pod 启动时，Kubernetes 不会发送 Liveness 或 Readiness 探测。如果是这样，它们可能会干扰应用程序的启动。
您可以在此链接上获取有关探测器如何工作的更多信息：