为java web应用程序设置kubernetes livenessProbe是否有用？

Question

我已经看到很多帖子将livenessProbe设置为java web应用程序的健康端点。以springboot为例：

livenessProbe:
            httpGet:
              path: /actuator/health
              port: http

但据我所知，下面的命令是dockerfile的最后一行，它已经隐式地保证了与livenessProbe的相同。

CMD ["-c", "/usr/bin/java ${DOCKER_JAVA_OPTS} -jar YOUR_JAR.jar"]

也就是说，如果java应用程序崩溃，会创建一个新的pod，因此，不需要为java应用程序设置livenessProbe？

对我来说，将readinesProbe设置为与livenessProbe相同也没有意义，因为当livenessProbe传递时，readinessProbe肯定会传递，而readinessProbe更有用，因为在容器运行之后，应用程序必须初始化一些连接，并且必须等待初始化。

我看到的一个例子是，许多帖子同时使用livenessProbe和readinessProbe，并且两者都调用相同的健康端点。

        livenessProbe:
            httpGet:
              path: /actuator/health
              port: http
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: http

Answer 1

Kubernetes只会在主容器进程结束时重启pod，而不是在它停止响应或挂起时重启。livenessProbe旨在重新启动无响应的容器。

我不建议让readinessProbe和livenessProbe完全相同。您至少应该对initialDelay使用不同的值(延迟小于readinessProbe的启动时间，大于livenessProbe的启动时间)。如果您的livenessProbe延迟太短，您的应用程序将被终止并在其完全启动之前重新启动。

readinessProbe应指示您的容器是否已准备好响应请求。如果livenessProbe失败，则应指示应用程序挂起并应重新启动。对于许多没有复杂健康检查的简单应用程序，这种情况是相同的，因此它们使用相同的测试。如果您有更细粒度的健康检查，则可以对这两个探针进行不同的测试。另一个不同的例子可能是，您知道您的健康检查偶尔会因为一些间歇性问题而失败，这些问题会自行解决。在这种情况下，我建议您增加livenessProbe的failureThreshold。

因此，一般来说，我会使readinessProbe比livenessProbe更严格。这样，您可以确保仅将请求发送到响应的pod，但避免不必要的重启。显然，您需要考虑应用程序的具体情况。

Answer 2

1. 不要将b/w pod与容器混淆。一个pod可以运行多个容器。

1. 不要把“容器运行”和“应用程序运行”搞混了。您的应用程序可能依赖于多个因素，如数据库是否已启动？单点登录是否有效？

作为一个原则，从系统的角度而不是从开发人员的角度来关注需要测试可用性的内容。您的应用程序可能正在运行，但可能是死锁或抛出与数据库相关的错误。因此，建议进行pod级运行状况检查，而不是容器级检查。