我正在开发使用Spring服务和OpenShift部署它。目前，我正在使用Spring Actuator健康端点作为Kubernetes的生存和准备探测。Kubernetes - 活性与准备探头实现

不过，我会打电话添加到另一个服务于一体的致动器的健康终点，它看起来对我来说，在这种情况下，我需要实现新的活跃度探头为我服务。如果我不这样做，那么第二项服务中的失败将导致活性探测失败失败，并且Kubernetes将在没有任何实际需求的情况下重新启动我的服务。

那是正确的，对于活跃度探头，实现一些简单的REST控制器，它总是返回HTTP状态200？如果有效，该服务总能被视为活着？还是有更好的方法来做到这一点？

2017-09-02 dplesa

你是什么意思与“我将在执行机构的健康端点的呼叫添加到另一个服务”？每个健康端点只应提供有关*本身*的信息，而不是其他服务。 – user3151902

情况是，如果第一个依赖的第二个服务不起作用，那么第一个服务也不起作用。 – dplesa

这不是Kubernetes的意图。正如我所说的，健康/活力探针应*只*检查特定服务。我同意这么随意的答案，总是返回200可能掩盖真正的错误与服务。 – user3151902

活跃度探头

仅包括您认为这些检查，如果失败，将得到与吊舱重启治愈。有一个总是返回一个HTTP 200的新端点没有任何问题，它将作为活动探测端点;前提是您拥有独立的监控，并且已为您的首个服务所依赖的其他服务提供警报。简单的http 200 liveness有什么用处？那么，让我们考虑这些例子。

如果你的应用程序是一个基于非反应性线程的应用程序（基于servlet的应用程序 - 如应用在Tomcat上运行 - 这是春天开机1.X的默认选项），在的情况下，重载它可能变得没有反应，并且一个重新启动将会有帮助。
如果你配置的内存没有，而你开始你的应用程序;在重载的情况下，应用程序可能会超出吊舱分配的内存，并且应用程序可能无响应，然后吊舱重新启动将有所帮助。

准备探头

有两个方面给它。

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

来源

2017-09-04 03:23:50

是的，我完全理解这些情况。然而，我主要关心的是活跃性探测，如果可以将其作为简单的REST控制器来实现，它将始终返回HTTP状态200. – dplesa

@dplesa ..道歉！我更新了我的答案。 –

Kubernetes - 活性与准备探头实现

回答

活跃度探头

准备探头

相关问题