我正在构建一些Spring Boot微服务，这些服务将部署在Kubernetes（专用于AKS）集群中。我打算为 活动和就绪状态 检查设置probePaths，以同时指向执行器运行状况端点，但是我想知道这是否不是最佳选择。我最初的想法是检查路径将很有用（至少对于准备就绪而言），以便在Spring启动并能够处理请求之前，不向其发送流量。由于这些服务使用数据库连接，并且如果执行器运行状况指示器无法建立连接，则执行器运行状况指示器将报告状态为关闭，这不是一个好主意吗？
考虑到它的活动性，我想它可能会一遍又一遍地回收豆荚/容器，即使它可能无法解决任何问题。（如果数据库已关闭）。
准备就绪后，我认为如果数据库关闭，这可能会导致可用应用程序池为0。如果数据库关闭，则该应用程序本身很有可能不是很有用，但是我认为某些部件可能仍然可以工作。
对于这种类型的事情，是否有推荐的最佳实践？
答案 0 :(得分：5)
从Spring Boot 2.3开始，核心和the Availability state of the application支持can be exposed as Kubernetes Probes with Actuator（包括活跃性和就绪性）。
您的问题就来了，the Spring Boot issue for the Liveness/Readiness feature中对此进行了详尽的讨论。
/health端点从来没有真正设计过公开应用程序状态并驱动云平台如何对待应用程序实例并向其路由流量。自从Spring Boot在这里提供更好的功能以来，就已经使用了很多这种方式。
Liveness仅在应用程序的内部状态损坏并且我们无法从中恢复时才会失败。正如您在问题中强调的那样，如果外部系统不可用，则在此失败会很危险：该平台可能会根据该外部系统（可能是全部？）回收所有应用程序实例，并导致级联故障，因为其他系统可能也取决于该应用程序。
默认情况下，除非应用程序本身更改了内部状态，否则活动问题将以“成功”答复。
Readiness探测实际上是关于应用程序服务流量的能力。正如您已经提到的，某些运行状况检查可能会显示应用程序关键部分的状态，而其他一些则不会。 Spring Boot会将Readiness状态与应用程序的生命周期进行同步（Web应用程序已启动，已请求正常关闭，并且我们不应再路由流量，等等）。有一种方法可以配置“就绪”运行状况组，以包含针对特定用例的一组自定义运行状况检查。
我不同意答案中的一些陈述，特别是因为在Spring Boot中由于以下原因发生了很多变化：
/actuator/health用于“活跃度”或“就绪”探针。ApplicationRunner bean进行移动-它们将在Liveness为Success之后但在Readiness为Success之前执行。如果对于配置的探针而言，应用程序启动仍然太慢，则应使用超时时间更长的StartupProbe，并将其指向Liveness端点。有关此新功能的更多信息，您可以阅读专门的Kubernetes Liveness and Readiness Probes with Spring Boot博客文章。
答案 1 :(得分：2)
使用运行状况检查来检查应用是否已准备好处理新请求。可以在/actuator/health中实现。另请参见下面的 StartupProbe 。
高负载下吗？
如果您的应用处于高负载下，则它可能无法及时进行运行状况检查，从而导致 ReadinessProbe 失败 。考虑使用Horizontal Pod Autoscaler获得更多副本来处理负载。
如果您的应用处于不可恢复的状态，则最好能够自行终止，例如使用java.lang.System.exit(1)。如果应用程序可能陷入僵局，无法继续，请考虑为LivenessProbe实现端点，此 可能与ReadinessProbe相同。
长时间未响应准备就绪
如果您的应用长时间未响应 ReadinessProbe ，例如很多分钟，可能出了点问题（除非您期望应用会发生这种情况），那么您可能还应该将/actuator/health作为您的 LivenessProbe ，但具有更高的failureThreshold和高 initialDelaySeconds（例如几分钟）
ReadinessProbe 在应用启动过程中最有用，因为它可能需要加载例如数据准备好接收请求之前-但 ReadinessProbe 在Pod生命周期中会定期执行。 StartupProbe is now a better alternative用于将启动缓慢的应用程序与 LivenessProbe 结合使用，后者仅在 StartupProbe 之后才有效。您可能仍需要 ReadinessProbe 来通知Pod已准备好处理请求。
如果您的应用依赖于其他服务，这些服务不健康-最好让您的应用从这些情况下恢复，当备份服务再次启动时，例如重新连接。否则，如果您的服务链在 ReadinessProbe 或 LivenessProbe 上不响应，则这将是 domino链反应。连锁有问题。考虑提供降级服务，通知您尚未提供全面服务，也许您的某些端点仍然可以正常工作。
它是发送探测请求的同一节点上的 kubelet 。考虑对探针使用Management Server Port。您无需将此端口暴露给Service，最好将一个端口用于 http ，将另一个端口用于 management 。
如果您正在使用Cloud Provider Load Balancer，它可能会对您的服务进行运行状况检查，并且您可能需要配置其发送运行状况检查的路径，例如Google Cloud Platform默认为/。这是对服务的健康检查，而不是针对各个 Pod 的健康检查。
答案 2 :(得分：0)
我们已将Spring boot Actuator自定义运行状况检查用于活动性和就绪状态检查。您可以使用自定义逻辑来确定您是否能够满足请求。如果您能够处理请求，则保持Pod处于活动状态，否则重新启动它。对于数据库连接问题，仅当您的连接被卡住而不释放时，重新启动才有用。
答案 3 :(得分：0)
我们正在使用标准的/ actuator / health端点进行活动和就绪状态的评估，并且已经使用了将近一年。积极的一面是，除非所有应用程序的连接都已启动并正在运行，否则该应用程序未标记为可使用。不利方面是由于某些情况下的连接错误，导致停机/重启。
在我看来，不与数据库（或其他重要基础结构）保持连接的应用程序就像没用一样好。由于它可能无法正常运行，因此您最好报告它不可用。因此，除非您遇到与数据库的连接不良或其他问题，否则我真的看不到使用/ actuator / health既活泼又准备就绪的危害。而且，这是一种检查应用程序是否已启动并运行的廉价方法，只需很少的手动工作即可完成设置。