Spring Boot应用程序+ Kubernetes活动/准备情况检查

Question

我正在构建一些Spring Boot微服务，这些服务将部署在Kubernetes（专用于AKS）集群中。我正计划将活动性和就绪性检查的probePath设置为同时指向执行器运行状况端点，但我想知道这是否不是最佳选择。我最初的想法是，检查路径将很有用（至少对于就绪状态而言），以便在Spring启动并能够处理请求之前，不向其发送流量。由于这些服务使用数据库连接，并且如果执行器运行状况指示器无法建立连接，则执行器运行状况指示器将报告状态为关闭，这不是一个好主意吗？

考虑到活动性，我认为它可能会一遍又一遍地回收豆荚/容器，即使（在数据库关闭的情况下）它可能无法解决任何问题。

准备就绪后，我认为如果数据库关闭，这可能会导致可用应用程序池为0。如果数据库关闭，该应用程序本身很有可能不是很有用，但是我认为某些部件可能仍然可以工作。

对于这种事情是否有建议的最佳实践？

Answer 1

从 Spring Boot 2.3 开始，应用程序的可用性状态（包括 Liveness 和 Readiness）在核心中得到支持，并且可以作为 Kubernetes Probes with Actuator 公开。

您的问题是正确的，这在Spring Boot 问题的 Liveness/Readiness 功能中进行了详细讨论。

该/health端点从来没有真正的设计，露出应用程序状态和如何推动云平台对待应用程序实例它和流量路由到它。自从 Spring Boot 在这里提供了更好的功能以来，它已经被大量使用。

在Liveness当应用程序的内部状态被打破只能失败，我们无法从中恢复。正如您在问题中强调的那样，一旦外部系统不可用，就在这里失败可能是危险的：平台可能会根据该外部系统（可能是全部？）回收所有应用程序实例并导致级联故障，因为其他系统也可能取决于该应用程序。

默认情况下，活性问题将回复“成功”，除非应用程序本身更改了该内部状态。

该Readiness探测器是真正关于应用服务流量的能力。正如您所提到的，一些健康检查可能会显示应用程序重要部分的状态，而另一些则不会。Spring Boot 会将就绪状态与应用程序的生命周期同步（Web 应用程序已启动，已请求正常关闭，我们不应再路由流量等）。有一种方法可以配置“就绪”运行状况组，以包含针对您的特定用例的一组自定义运行状况检查。

我不同意收到赏金的答案中的一些陈述，特别是因为 Spring Boot 发生了很多变化，因为：

1. /actuator/health从 Spring Boot 2.3.0 开始，您不应使用Liveness 或 Readiness 探针。
2. 使用新的 Spring Boot 生命周期，您应该将所有长时间运行的启动任务作为ApplicationRunnerbean 移动 - 它们将在 Liveness is Success 之后执行，但在 Readiness is Success 之前执行。如果应用程序启动对于配置的探测器来说仍然太慢，那么您应该使用具有更长超时时间的 StartupProbe 并将其指向 Liveness 端点。
3. 使用管理端口可能很危险，因为它使用单独的 Web 基础架构。例如，管理端口上公开的探针可能没问题，但主连接器（为客户端提供实际流量）可能不堪重负，无法提供更多流量。在某些情况下，为探测器重用相同的服务器和 Web 基础设施可能会更安全。

有关此新功能的更多信息，您可以阅读专用的Kubernetes Liveness and Readiness Probes with Spring Boot博客文章。