Openshift / Kubernetes中的弹簧启动执行器健康检查

Question

我们有一种情况，我们有大量的Spring启动应用程序在容器中运行（在OpenShift上），访问集中式基础设施（在容器外部），如数据库，队列等。

如果一个中央基础设施停机，健康检查会返回“不健康”（理所当然）。问题是，生动性检查看到了这一点，并重新启动pod（准备检查然后看到它也下降，所以不会启动应用程序）。当只有少数可用时，这很好，但如果许多（可能是数百个）应用程序正在使用它，它会强制重新启动所有应用程序（崩溃循环）。

我知道中央基础设施瘫痪是一件坏事。它“应该”永远不会发生。但是......如果确实如此（墨菲定律），它会让容器陷入狂热之中。看起来我们要么做错了，要么我们应该重新配置一些东西。

几个问题：

• 如果您被迫使用在OpenShift / Kubernetes上的容器中运行的Spring启动应用程序的集中式基础架构，是否仍应为后端启用所有执行器检查？ （无论如何，弹回容器真的不会修复后端）
• 是否应为活动探测器和准备探测器设置/执行器/运行状况端点？
• 民间用于春季启动应用程序中的准备/活性探测的常用设置是什么？ （超时/间隔/等）。

Answer 1

1. 使用执行器检查实时性/就绪性是在Spring Boot Pod中检查健康应用程序的事实上的方法。如果一个核心部分（例如数据库或队列服务）出现故障，您的应用程序一旦启动，理想情况下应该不会出现故障或变得不健康，理想情况下，您应该添加某种弹性，以便连接到备用DR站点或等待一定时间中央服务重新上线和应用重新连接的时间段。这更像是后端方面的技术故障，导致应用程序在干净启动后出现功能故障。
2. 是的，生活和准备都是必需的，因为它们都有不同的用途。阅读this
3. 在我之前的一个项目中，用于准备就绪的设置大约为30秒，活动时间大约为90，但说实话，这完全取决于您的应用程序，如果您的应用程序需要1分钟才能启动，那么您的准备时间应该是配置为，您的活跃度应该与您的后端服务的故障转移切换所需的任何时间一致。

希望这可以帮助。