问题标签 [livenessprobe]

我有一个在 Kubernetes 上运行的 pod，我正在为其设计一个活性探针。我的应用程序从队列中读取数据（通过一个循环不断搜索新消息并在找到时执行其他功能）并且没有通过 HTTP 公开，因此我需要一个命令活性探测。我正在考虑一个简单的实现是否可行：

但是，我不确定cat即使应用程序在循环中的某个点“卡住”是否会成功——文件仍然存在。这归结为对我无法在文档中找到的活性探针的基本缺乏了解 - 大概它们以某种方式与您的应用程序串联运行，因此如果您的应用程序未运行，则无法执行命令？但我对这一点没有信心。

如果该命令可以并行执行，那么我相信我将需要某种时间戳检查，在每个循环上更新一个文件，并且 liveness 探针检查它的时间戳。如果第一种方法可行，它会更简单，但任何人都可以确认是否是这种情况？谢谢。

编辑：我的应用程序代码。我在 sleep(60)s 中添加了尝试测试如果文件没有在一分钟内更新，liveness 探测是否会失败，但它们不会是正常应用程序代码的一部分。

我的活性探测尝试：

1.

2. （如果从 find 返回任何内容，命令返回失败，否则 cat 文件）

3. （如果从 find 返回任何内容，则命令返回失败，否则不返回任何内容）

我也用 - 而不是 + 尝试了所有这些。尽管窗口非常短（最终会更长！）和 sleep 命令，但探测永远不会失败。

什么是适合livenessProbe后台进程的 Kubernetes 命令？

我们有一个 NodeJS 进程，它使用 SQS 队列中的消息。由于它是一项后台作业，我们不公开任何 HTTP 端点，因此活性命令似乎是进行活性检查的更合适的方式。一个“足够好”的命令设置实际上会检查进程是否处于活动状态并正常运行？NodeJS 进程是否应该触摸一个文件以更新其编辑时间并且活性检查验证这一点？我在网上看到的示例似乎与实际过程脱节，例如他们检查文件是否存在。

我正在使用 Kubernetes字段测试 Spring Boot 2.3（server.shutdown=graceful 和 Tomcat Web 服务器）中的新功能正常关闭。terminationGracePeriodSeconds当正常关闭阶段开始时，新的 HTTP 请求按预期被拒绝，此时应详细说明当前请求，直到可配置的超时 ( spring.lifecycle.timeout-per-shutdown-phase)。奇怪的行为是 Spring boot actuator liveness 结果，因为在这种情况下，liveness 端点是不可达的。

因此，kubelet 无法知道微服务在关闭期间是否还活着，或者因为其他事情而卡住了。由于K8s liveness probe不依赖terminationGracePeriodSecondsfield，POD会根据自己的K8s liveness配置重启，Spring boot微服务因为野蛮重启无法优雅关闭。

我错过了什么吗？我该如何管理这种情况？

有kubernetes微服务（用 .net core 3.1 编写）具有活性探测。当这个 liveness probe 检测到一些其他外部资源（例如 redis、rabbitmq）不可访问时，kubernetes 会重启服务的容器。重启机制按预期工作。

问题是kube重启服务容器后，服务仍然无法连接到资源。似乎连接问题无法通过 kube liveness 重启来解决。在这种情况下，唯一的解决方案（解决方法）是服务重新部署。如果重新部署特定服务，连接问题将立即停止。

服务部署和活动探针重启之间有什么区别，在部署的情况下使连接再次工作？

我在 OpenShift Pod 中运行 Spring Boot 2.0.0 应用程序。为了执行就绪和活跃度探测，我依赖于 spring boot 执行器健康检查。我的应用程序属性文件具有以下属性：

以下是readiness和liveness探针的相关配置。

我的期望是，我的准备和活跃度探测应该会因这些随机 url 而失败，但它们会成功。不知道我在这里缺少什么。请帮助。

我正在为我的 kafka 集群运行 3 个 zookeeper kubernetes statefulset。命名为 zookeeper-0、zookeeper-1、zookeeper-2。而且我使用 ruok 命令启用了活跃度探测。如果任何 statefulset pod 由于任何故障而重新启动，则仲裁将失败，并且即使在失败的 pod 启动并且其 liveness 探测响应正常之后，zookeeper 也会停止工作。

发生这种情况时，我必须手动重新启动所有 zookeeper 实例才能使其恢复工作。当我进行 helm 升级时也会发生这种情况。因为当我进行 helm upgrade 时，第一个重启的实例是 zookeeper-2，然后是 zookeeper-1，最后是 zookeeper-0。但似乎只有当我一起启动所有实例时，zookeeper 才会起作用。因此，每次 helm 升级后，我都必须手动重新启动所有实例。

我的问题是：

这种行为的原因可能是什么？另外，在 Kubernetes 环境中确保 100% 可靠的 statefulset zookeeper 的最佳方法是什么？

我将 kubernetes 中的 elasticsearch 图表从 6.6 升级到了 7.10.2 版本。数据和主 Pod 正在运行并准备就绪，但客户端尚未准备好（2 个客户端、2 个数据、3 个主控）。

这是他们的状态：

当我运行描述时，我看到了这个警告：

在 kubectl 日志中，我得到了这个

我将准备就绪和活跃度 initialDelaySeconds 设置为 90，这可能是什么问题？

我创建了一个启动探针并做了它，所以它总是会失败。它应该导致 pod 被杀死并重新启动，但事实并非如此。我看到启动探测失败的一个事件（之后没有事件），但 pod 显示为1/1 Running. 当我运行我的 Helm 测试时，它通过了！

我通过为启动探测检查设置无效的用户名和密码来保证失败。

使用 K8s 版本：1.19.4

当我检查事件时，我得到：

检查 Pod，我看到（使用--watch）：

请注意，它的重启次数为零。

我的部署有：

注意- mysqladmin ping -u wrong -pwrong以上。

值.yaml：

即使等待 5 分钟，我仍然能够运行测试（它使用 MySql 客户端访问数据库）并且它可以工作！为什么这不会失败？

我正在寻找一种方法，我们可以在 Rancher 上使用 configMap UI 打开/关闭活跃度探测，同时它不需要重新部署 pod。

详细说明：假设已经在 pod 上配置了 liveness probe。接下来我有一个布尔标志，它被设置为 false，所以如果为 false，liveness probe 将停止对 pod 的探测。在其他时候，如果将布尔标志设置为 true，则 liveness probe 将恢复探测。所有这些都需要在不重新部署 pod 的情况下工作。以下是我的草稿想法：

1. 有一个 configMap UI（在 Rancher 上列出的 configMap），它持有布尔标志来打开/关闭活性探测，如下所示：

2. 接下来，我想通过条件检查将上述布尔标志吸收到 deployment.yaml 中，如下所示：

3. 我不确定如何将 Rancher 上的 configMap 布尔标志引用到 deployment.yaml 文件中。
4. 或者是否有任何其他方法可以在不重新部署 pod 的情况下控制 liveness probe 的开/关切换。

我正在使用 Spring Boot 应用程序。我已经使用 REST API 端点包含了 http liveness probe config。因此，只要 REST API 无法访问，Kubernetes 就会重新启动 pod。

问题是，我需要确定是否有任何方法可以区分由 Liveness Probe 触发的 Pod 重启活动与部署团队完成的手动重启。

每当重新启动 Pod 时，Kubernetes 是否会在 Spring Boot 日志中包含任何类型的日志消息？