Kubernetes-活动性和就绪性探测器的实现

Question

我正在使用Spring开发一个服务，并将其部署在OpenShift上。目前，我正在使用Spring Actuctor health endpoint作为Kubernetes的活跃度和就绪度探测器。

但是，我将在执行器健康endpoint中添加一个对另一个服务的调用，在这种情况下，我认为我需要为我的服务实现新的活跃度探测。如果我不这样做，那么第二个服务的失败将导致活跃度探测失败，Kubernetes将重新启动我的服务，而没有任何实际需要。

对于活跃度探测，是否可以实现一些简单的REST控制器，它将始终返回HTTP状态200？如果它能工作，服务就可以一直被认为是活动的？或者有没有更好的办法来做呢？

Answer 1

包括那些您认为如果失败,将通过pod重新启动而被治愈的检查。拥有一个总是返回HTTP200的新endpoint并没有错，它将用作活跃度探测endpoint；前提是您对第一个服务所依赖的其他服务有独立的监视和警报。

一个简单的http 200活跃度有什么帮助？

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

如果在启动应用程序时没有配置内存；在负载较重的情况下，应用程序可能会超出POD分配的html" target="_blank">内存，并且应用程序可能会变得没有响应。吊舱重启对此也有帮助。

它有两个方面。

1）让我们考虑一个场景。假设在您的第二个服务上启用了身份验证。您的第一个服务（您的健康检查所在的位置）必须正确配置才能与第二个服务进行身份验证。

假设在后续的第一个服务部署中，您弄错了本应从configmap或Secret中读取的authheader变量名。并且您正在进行滚动更新。

如果您将第二个服务的http200也包含在（第一个服务的）健康检查中，那么这将防止错误版本的部署运行；您的旧版本将继续运行，因为您的新版本将永远无法通过健康检查。我们甚至不需要对身份验证进行那么复杂的操作，让我们只说第二个服务的url是在第一个服务中硬编码的，而您在第一个服务的后续版本中搞砸了这个url。健康检查中的这一附加检查将阻止buggy版本上线

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