Spring Boot应用程序+ Kubernetes活动/准备情况检查 [英] Spring Boot app + Kubernetes liveness/readiness checks

问题描述

我正在构建一些Spring Boot微服务，这些服务将部署在Kubernetes(专用于AKS)集群中.我打算为 liveness&准备就绪 ，检查是否都指向执行器运行状况终点，但想知道这是否不是最佳选择.我最初的想法是，检查路径将很有用(至少对于准备就绪而言)，以便在Spring启动并能够处理请求之前才将流量发送给它.由于这些服务使用数据库连接，并且如果执行器运行状况指示器无法建立连接，则执行器运行状况指示器将报告状态为关闭，这不是一个好主意吗?

I'm building a few Spring Boot microservices that are getting deployed in a Kubernetes (AKS specifically) cluster. I was planning on setting the probePaths for the liveness & readiness check to both point at the actuator health endpoint, but was wondering if that may not be the best option. My original thinking was that checking the path would be useful (at least for readiness) so that traffic wouldn't be sent to it until Spring has started up and is capable of handling requests. Since these services use a database connection, and the actuator health indicator will report status as down if it can't make a connection, will that not be such a good idea?

活泼的我在想，它可能会一遍又一遍地回收豆荚/容器，尽管(如果数据库已关闭)它可能无法解决任何问题.

With liveness, I'm thinking it might start recycling the pods/containers over and over even though (in the case the DB is down) it might not fix anything.

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

With readiness, I'm thinking it might cause the pool of available apps to be 0 if the DB is down. The app itself will most likely not be very useful if the DB is down, but parts may still work potentially I suppose.

对于这种事情，是否有推荐的最佳实践?

Is there a recommended best practice for this type of thing?

推荐答案

从Spring Boot 2.3开始，可以作为带有执行器的Kubernetes探针公开.

As of Spring Boot 2.3, the Availability state of the application (including Liveness and Readiness) is supported in the core and can be exposed as Kubernetes Probes with Actuator.

您的问题已经提出，并且在中进行了详细讨论Live/Readiness功能的Spring Boot问题.

Your question is spot on and this was discussed at length in the Spring Boot issue for the Liveness/Readiness feature.

/health端点从来没有真正设计过公开应用程序状态并驱动云平台如何对待它的应用程序实例并向其路由流量.自从Spring Boot在这里提供更好的功能以来，就已经使用了很多这种方式.

The /health endpoint was never really designed to expose the application state and drive how the cloud platform treats the app instance it and routes traffic to it. It's been used that way quite a lot since Spring Boot didn't have better to offer here.

Liveness仅在应用程序的内部状态损坏并且我们无法从中恢复时才会失败.正如您在问题中强调的那样，如果外部系统不可用，则在此处立即失败很危险:该平台可能会根据该外部系统(可能是全部?)回收所有应用程序实例，并导致级联故障，因为其他系统可能也取决于该应用程序.

The Liveness should only fail when the internal state of the application is broken and we cannot recover from it. As you've underlined in your question, failing here as soon as an external system is unavailable can be dangerous: the platform might recycle all application instances depending on that external system (maybe all of them?) and cause cascading failures, since other systems might be depending on that application as well.

默认情况下，除非应用程序本身更改了内部状态，否则活动问题将以成功"答复.

By default, the liveness proble will reply with "Success" unless the application itself changed that internal state.

Readiness探针实际上与应用程序服务流量的能力有关.如您所提到的，某些运行状况检查可能会显示应用程序关键部分的状态，而其他一些则不会. Spring Boot会将Readiness状态与应用程序的生命周期进行同步(Web应用程序已启动，已请求正常关闭，并且我们不应再路由流量，等等).有一种方法可以配置就绪"运行状况组，以包含针对特定用例的一组自定义运行状况检查.

The Readiness probe is really about the ability for the application to serve traffic. As you've mentioned, some health checks might show the state of essential parts of the application, some others not. Spring Boot will synchronize the Readiness state with the lifecycle of the application (the web app has started, the graceful shutdown has been requested and we shouldn't route traffic anymore, etc). There is a way to configure a "readiness" health group to contain a custom set of health checks for your particular use case.

我不同意得到赏金的答案中的一些陈述，特别是因为在Spring Boot中由于以下原因发生了很多变化:

I disagree with a few statements in the answer that received the bounty, especially because a lot changed in Spring Boot since:

1. 从Spring Boot 2.3.0开始，您不应将/actuator/health用于活跃度"或就绪"探针.
2. 对于新的Spring Boot生命周期，您应该将所有长时间运行的启动任务作为ApplicationRunner bean进行移动-它们将在Liveness为Success之后但在Readiness为Success之前执行.如果对于配置的探针而言，应用程序启动仍然太慢，则应使用超时时间更长的StartupProbe，并将其指向Liveness端点.
3. 使用管理端口可能很危险，因为它使用的是单独的Web基础结构.例如，暴露在管理端口上的探针可能没问题，但是主连接器(为客户端的实际流量提供服务)可能不堪重负，无法为更多流量提供服务.在某些情况下，将探针重复使用相同的服务器和Web基础结构会更安全.

1. You should not use /actuator/health for Liveness or Readiness probes as of Spring Boot 2.3.0.
2. With the new Spring Boot lifecycle, you should move all the long-running startup tasks as ApplicationRunner beans - they will be executed after Liveness is Success, but before Readiness is Success. If the application startup is still too slow for the configured probes, you should then use the StartupProbe with a longer timeout and point it to the Liveness endpoint.
3. Using the management port can be dangerous, since it's using a separate web infrastructure. For example, the probes exposed on the management port might be OK but the main connector (serving the actual traffic to clients) might be overwhelmed and cannot serve more traffic. Reusing the same server and web infrastructure for the probes can be safer in some case.

有关此新功能的更多信息，您可以阅读专用的

For more information about this new feature, you can read the dedicated Kubernetes Liveness and Readiness Probes with Spring Boot blog post.

这篇关于Spring Boot应用程序+ Kubernetes活动/准备情况检查的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！