活力探测

Question

我正在使用Spring开发一个服务并在OpenShift上部署它。目前我正在使用Spring Actuator健康终端作为Kubernetes的活跃度和准备度调查。

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

对于活跃度探测，是否可以实现一些简单的REST控制器，它始终会返回HTTP状态200？如果它工作，服务总是可以被认为是活着的？或者有更好的方法吗？

Answer 1

活力探测

只包括您认为如果失败，将通过重新启动pod来治愈的那些检查。拥有一个始终返回HTTP 200的新端点没有任何问题，它将作为活动探测端点;只要您对第一项服务所依赖的其他服务有独立的监控和警报。

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

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

如果你的应用程序是一个单线程的每个http请求应用程序（基于servlet的应用程序 - 就像在tomcat上运行的应用程序 - 这是spring boot 1.X的默认选择），在这种情况下重载可能会变得没有反应。 pod重启将有助于此。
如果您在启动应用程序时未配置内存;在重负载的情况下，应用程序可能会超出pod分配的内存，应用程序可能会无响应。 pod重启也会有所帮助。

准备探针

它有两个方面。

1）让我们考虑一个场景。可以说，您的第二项服务启用了身份验证。您的第一项服务（您的健康检查所在地）必须正确配置以通过第二项服务进行身份验证。

我们只是说，在你的第一个服务的后续部署中，你搞砸了你应该从配置图或秘密中读取的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

Answer 2

在Spring Boot 2.0+中，使用Spring Boot Actuator实现准备就绪探针非常简单：

@Component
@Endpoint(id = "readiness")
public class ReadinessEndpoint {

    @ReadOperation
    public String getReadiness() {
        // do a custom check for readiness
        if (...) {

        } else {
            throw new RuntimeException("Not ready");
        }
    }
}

然后可以在/actuator/readiness上使用此端点（默认情况下）。

Answer 3

尽管我回复晚了一点。但是我认为我的实现将帮助人们将来为Spring Boot应用程序实现kubernetes就绪/活跃性探针。

我的docker映像的描述

从高山linux构建
Spring boot 2应用程序，只能通过SSL访问
由弹簧启动执行器实现的/ actuator / health返回{“ status”：“ UP”}

所以我不能使用kubernetes的httpGet选项，因为它仅使用http协议。

这就是为什么我在docker映像中创建一个小的shell脚本“ check-if-healthy.sh”作为状态的原因

check-if-healthy.sh
===================
curl -k https://localhost:8888/actuator/health | grep '"status":"UP"' > /dev/null && exit 0 || exit 1

请注意，您需要将此脚本添加到docker映像中，以便它可以在运行的容器中使用并且可以被kubernetes访问，因为kubernetes将触发“ docker exec / bin / ash / home / config-server /检查是否健康。” 像这样

COPY docker/check-if-healthy.sh /home/config-server/check-if-healthy.sh

然后使用kubernetes准备就绪探针的“ exec”选项调用这样的脚本。

      readinessProbe:
        exec:
          command:
            - /bin/ash
            - /home/config-server/check-if-healthy.sh
        initialDelaySeconds: 5
        timeoutSeconds: 1
        failureThreshold: 50
      livenessProbe:
        exec:
          command:
            - /bin/ash
            - /home/config-server/check-if-healthy.sh
        initialDelaySeconds: 5
        timeoutSeconds: 1
        failureThreshold: 50

Answer 4

Spring Boot 2.3内置了对“活动性和就绪性”探针的支持：

Spring Boot 2.3具有关于应用程序可用性的内置知识，可以跟踪应用程序是否处于活动状态以及是否已准备好处理流量。

在Kubernetes环境中，执行器将收集 Liveness and Readiness 信息并将其公开给健康小组。

"/actuator/health/liveness"

"/actuator/health/readiness"

有关更多详细信息，请检查blog post和documentation

文档摘要：

应用程序的活动状态指示内部状态是否有效。如果Liveness被破坏，则意味着应用程序本身处于故障状态，无法从中恢复。在这种情况下，最好的做法是重新启动应用程序实例。例如，如果本地缓存已损坏且无法修复，则依赖于本地缓存的应用程序应失败其活动状态。

“就绪”状态指示应用程序是否已准备好接受客户端请求。如果就绪状态尚未就绪，则Kubernetes不应将流量路由到该实例。如果应用程序太忙于处理任务队列，则它可以将自己声明为忙碌，直到可以再次管理其负载为止。

Kubernetes - 活力和准备情况调查实施

4 个答案:

活力探测

准备探针

Spring Boot 2.3内置了对“活动性和就绪性”探针的支持：