Spring Boot 应用程序 + Kubernetes 活动/就绪检查

Question

我正在构建一些部署在 Kubernetes（特别是 AKS）集群中的 Spring Boot 微服务。 我计划将用于活动和就绪检查的probePaths 设置为执行器健康端点的两个点，但想知道这是否可能不是最佳选择。 我最初的想法是检查路径会很有用（至少对于准备就绪），以便在 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. 从 Spring Boot 2.3.0 开始，您不应将/actuator/health用于 Liveness 或 Readiness 探针。
2. 使用新的 Spring Boot 生命周期，您应该将所有长时间运行的启动任务移动为ApplicationRunner bean - 它们将在 Liveness is Success 之后执行，但在 Readiness is Success 之前执行。 如果应用程序启动对于配置的探测器来说仍然太慢，那么您应该使用具有更长超时时间的 StartupProbe 并将其指向 Liveness 端点。
3. 使用管理端口可能很危险，因为它使用单独的 Web 基础架构。 例如，管理端口上公开的探针可能没问题，但主连接器（为客户端提供实际流量）可能不堪重负，无法提供更多流量。 在某些情况下，为探测器重用相同的服务器和 Web 基础设施可能会更安全。

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

Answer 2

ReadinessProbe - 应用程序是否准备好处理请求？

使用运行状况检查来检查应用程序是否已准备好处理新请求。 这可以在/actuator/health 。 另请参阅下面的StartupProbe 。

高负荷下？

如果您的应用在高负载下，它可能无法及时响应健康检查，从而导致ReadinessProbe失败。 考虑使用Horizo​​ntal Pod Autoscaler来获取更多副本来处理负载。

LivenessProbe - 应用程序是否陷入僵局？

如果您的应用程序处于不可恢复状态，最好是它可以自行终止，例如使用java.lang.System.exit(1) 。 如果应用程序可能会死锁，无法继续，请考虑为LivenessProbe实现一个端点，这可能与ReadinessProbe相同。

很长一段时间没有响应准备就绪

如果您的应用程序在很长一段时间内（例如几分钟）都没有响应ReadinessProbe ，则可能出现问题（除非您希望应用程序发生这种情况），那么您可能还应该将/actuator/health作为LivenessProbe但使用较高的failureThreshold和较高的initialDelaySeconds （例如几分钟）

StartupProbe - Kubernetes 1.16+ 上更好的选择

ReadinessProbe在应用程序启动期间最有用，因为它可能需要在准备接收请求之前加载例如数据 -但ReadinessProbe在 pod 生命周期期间定期执行。 StartupProbe 现在是与LivenessProbe结合使用的慢启动应用程序的更好替代方案， LivenessProbe仅在StartupProbe之后有效。 您可能仍然需要一个ReadinessProbe来通知 pod 已准备好处理请求。

取决于其他服务

如果您的应用程序依赖于其他不健康的服务- 如果您的应用程序可以从这些情况中恢复，当支持服务再次启动时（例如重新连接），则更好。 否则，如果您的服务链由于链中的最后一个应用程序出现问题而没有响应ReadinessProbe或LivenessProbe，这将是多米诺链反应。 考虑提供降级服务，通知您未处于全面服务状态，也许您的某些端点仍然可以正常工作。

使用管理服务器端口

发送探测请求的是同一节点上的kubelet 。 考虑使用管理服务器端口进行探测。 您不需要将此端口公开给Service ，最好将一个端口用于http而另一个用于management 。

云提供商负载均衡器服务健康检查

如果您使用的是 Cloud Provider Load Balancer，它可能会对您的服务进行健康检查，并且您可能需要配置它发送健康检查的路径，例如Google Cloud Platform默认为/ 。 这是对Service的健康检查，而不是针对单个Pod 。

Answer 3

我们已经使用 Spring boot Actuator 自定义健康检查进行 Liveness 和 Readiness 检查。 您可以使用自定义逻辑来确定您是否能够为请求提供服务。 如果您能够处理请求，则保持 pod 处于活动状态或重新启动它。 对于数据库连接问题，重启只会在您的连接卡住且未释放时有所帮助。

Answer 4

我们正在使用标准的 /actuator/health 端点来实现活跃度和就绪度，并且已经近一年了。 这样做的积极方面是应用程序不会被标记为可以使用，除非它的所有连接都已启动并正在运行。 不利的一面是由于某些错误连接的情况，这会导致停机/重新启动。

在我看来，与其数据库（或其他重要基础设施）没有任何连接的应用程序与无用一样好。 由于它可能无法正常运行，您不妨报告它不可用。 因此，除非您遇到与数据库或其他事情的连接不佳的问题，否则我真的看不出使用 /actuator/health 来实现活跃度和就绪度的危害。 此外，这是一种检查应用程序是否已启动并正在运行的廉价方法，只需很少的手动设置即可。