spring - Kubernetes-Liveness和Readiness探针实现

我正在使用Spring开发服务并将其部署在OpenShift上。目前，我正在使用Spring Actuator运行状况终结点来充当Kubernetes的 Activity 性和就绪状态探针。

但是，我将在Actuator运行状况端点中添加对另一个服务的调用，在我看来，在这种情况下，我需要为我的服务实现新的 Activity 性探针。如果我不这样做，那么第二个服务的失败将导致 Activity 性探针失败，并且Kubernetes将在没有任何实际需要的情况下重新启动我的服务。

对于 Activity 性探针，可以实现一些始终返回HTTP状态200的简单REST Controller 吗？如果有效，该服务始终可以被认为是有效的吗？还是有更好的方法呢？

最佳答案

活力探针

仅包括您认为如果失败将通过 pods 重启而治愈的那些检查。拥有一个始终返回HTTP 200的新端点(这将用作 Activity 探测端点)没有什么错；如果您对第一项服务所依赖的其他服务具有独立的监视和警报。

简单的http 200 Activity 在哪里有帮助？

好吧，让我们考虑这些例子。

如果您的应用程序是每个HTTP请求一个线程的应用程序(基于servlet的应用程序-例如在tomcat上运行的应用程序-这是spring boot 1.X的默认选择)，那么在繁重的情况下，它可能会变得无响应。重新启动广告连播会在这里有所帮助。

如果您在启动应用程序时未配置内存；如果负载很重，应用程序可能会超出Pod分配的内存，并且应用程序可能会变得无响应。重启pod也可以帮助您。

准备探针

它有两个方面。

1)让我们考虑一个场景。可以说，第二项服务启用了身份验证。您的第一个服务(运行状况检查所在的位置)必须正确配置才能通过第二个服务进行身份验证。

只是说，在您的第一个服务的后续部署中，您搞砸了应该从configmap或secret中读取的authheader变量名。您正在滚动更新。

如果(第一项服务的)运行状况检查中还包含第二项服务的http200，则将阻止部署的详细版本；您的旧版本将继续运行，因为您的新版本将永远不会通过运行状况检查。我们甚至可能不需要进行复杂的身份验证，而仅是说第二个服务的url在第一个服务中是硬编码的，而您在随后的第一个服务版本中搞砸了该URL。健康检查中的这项额外检查将阻止有问题的版本上线

2)另一方面，假设您的第一个服务具有许多其他功能，并且第二个服务中断了几个小时不会影响第一个服务提供的任何重要功能。然后，您一定可以从第一服务的运行状况检查中退出第二服务的状态。

无论哪种方式，您都需要为这两种服务设置适当的警报和监视。这将有助于决定何时进行干预。

我要做的是(忽略其他不相关的细节)，

readinessProbe:
  httpGet:
    path: </Actuator-healthcheck-endpoint>
    port: 8080
  initialDelaySeconds: 120
  timeoutSeconds: 5
livenessProbe:
  httpGet:
    path: </my-custom-endpoint-which-always-returns200>
    port: 8080
  initialDelaySeconds: 130
  timeoutSeconds: 10
  failureThreshold: 10