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

Question

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

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

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

Answer 1

活力探测

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

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

好吧,让我们考虑一下这些例子.

1. 如果你的应用程序是一个单线程每个http请求应用程序(基于servlet的应用程序 - 就像运行在tomcat上的应用程序 - 这是spring boot 1.X的默认选择),在重负载的情况下,它可能会变得没有响应.pod重启将有助于此.

2. 如果在启动应用程序时没有配置内存; 在重负载的情况下,应用程序可能会超出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