如何解决就绪探针和健康检查有什么好处？
我正在开发一个应用程序，我可以看到它正在执行多项运行状况检查？
- 数据库就绪探测
- 另一个 API 依赖准备情况调查
当我查看集群日志时，我意识到我的服务在数据库检查失败时只会抛出 500 并关闭。我在这里无法理解的是，如果数据库关闭或另一个 API 关闭，如果我没有准备就绪探测器，那么我的容器无论如何都会关闭。此外，我会看到我的应用程序确实抛出了一些 500，因为 DB 或其他服务已关闭。
无论如何，我的容器的就绪探针下降有什么好处？我的另一个问题是 Healthcheck 是不是只有在我将服务部署到集群时才应该考虑？如果不是集群微服务环境，是否会增加/减少执行健康检查的好处？
解决方法
就绪探针在几个地方使用。一个重要的问题是未就绪的 pod 从引用它们的所有服务中删除。它们对于 Deployments/StatefulSet 上的滚动更新也很重要，因为在新 pod 达到就绪状态之前滚动不会继续。一般来说，用于就绪探测的检查应该只检查当前服务。所以它不应该接触数据库。有时这很难实现，并且确实使它们变得不那么有用。但是检查每个 Pod 的内容，例如 Web 服务器正在侦听端口并可以返回 HTTP 响应。
,Kubernetes 使用三种类型的探测器来检查 Pod 的健康状况：
-
Liveness：告诉 Kubernetes 容器内部出现问题，最好重新启动它，看看 Kubernetes 是否可以解决错误。 -
Readiness：告诉 KubernetesPod已准备好接收流量。有时发生的事情不会使Pod完全丧失能力，但无法满足客户的要求。例如：失去与数据库的连接或第三方服务失败。在这种情况下，我们不希望 Kubernetes 重置Pod，但我们也不希望它向它发送无法满足的流量。当Readiness探测失败时，Kubernetes 从服务中删除Pod并停止与Pod的通信。错误解决后，Kubernetes 可以将其添加回来。 -
Startup：在Pod已启动并准备好接收流量时通知 Kubernetes。这些探针对于需要一段时间才能开始的应用程序特别有用。当Pod启动时，Kubernetes 不会发送Liveness或Readiness探测。如果是这样，它们可能会干扰应用程序的启动。 您可以在此链接上获取有关探测器如何工作的更多信息：
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
