问题标签 [livenessprobe]

在 GKE 上，我尝试使用 readiness probe/ liveness probe ，并使用监控https://cloud.google.com/monitoring/alerts/using-alerting-ui发布警报

作为测试，我创建了一个具有就绪探针/活性探针的 pod。正如我所料，探针检查每次都失败。

并检查 GCP 日志，两个错误日志都首先基于 periodSeconds 显示。

就绪探测：每 10 秒

2021-02-21 13:26:30.000 JST 就绪探测失败：HTTP 探测失败，状态码：500

2021-02-21 13:26:40.000 JST 就绪探测失败：HTTP 探测失败，状态码：500

活度探测：每 1 分钟

2021-02-21 13:25:40.000 JST Liveness 探测失败：HTTP 探测失败，状态码：500

2021-02-21 13:26:40.000 JST Liveness 探测失败：HTTP 探测失败，状态码：500

但是，在运行这个 pod 几分钟后

• 不再调用活性探针检查
• 已调用就绪探测检查，但间隔变长（最大间隔看起来约为 10 分钟）

在我的计划中，我将创建警报策略，其条件类似于

• 如果活性探测错误在 3 分钟内发生 3 次

但是如果探测检查没有像我预期的那样调用，那么这些策略就不起作用；即使 pod 没有运行，警报也已修复

为什么 Liveness 探针没有运行，而 Readiness 探针的间隔发生了变化？

注意：如果有其他好的警报策略来检查 pod 的活跃度，我不会在意这种行为。如果有人能建议我哪种警报策略最适合检查 pod，我将不胜感激。

开发一个 Spring Boot 应用程序（带有执行器），有时应用程序负载非常高（或“忙”，线程池已耗尽并且请求排在长队列中）以至于 liveness probe 可以很容易地决定重新启动它（而不是停留在一个队列）。

我想以某种方式让应用程序自行管理它而不是重新启动 pod。

阅读后： 当 Pod “忙”时指定给 Kubernetes我意识到 liveness & readiness 探针可以提供帮助。不幸的是，那里没有任何明确的答案，所以请提示我如何管理它？我可以以某种方式关闭活跃度探测并播放服务尚未准备好，因为它从一开始就已经准备好了？然后再开机？

编辑：解决方案是：management.server.port=8081或HPA(Horizontal pod autoscalar) which scale out the pod as traffic increases

我有一个应用程序在集群中每 1-2 秒创建僵尸进程。我在我的应用程序中使用 Process，但仅​​在我收到特定命令时才使用，而现在情况并非如此。

这是我所做的

在另一个终端，所以看看我是否有活动......

即使除了少数周期性 REST 调用（从其他应用程序轮询）外，我身边没有任何活动，僵尸仍然每 1-2 秒增加一次。在这一点上，我没有调用创建新 Process(..) 的方法

我错过了什么？

编辑 我创建了一个小脚本，它将通过节点中的应用程序打印僵尸。

编辑

我对 Containerd 有同样的问题。看起来问题出在 exec 探针上。

场景：一个 K8S pod 有多个容器，并且为每个容器配置了 liveness/readiness 探针。现在，如果活性探测在某些容器上成功而在少数容器上失败，k8s 会做什么。

1. 它会仅重新启动失败的容器
   吗？
2. 它会重新启动整个 pod。

在 KubernetesKubernetes Health Check Probes中，如果timeoutSeconds超过会发生什么periodSeconds？例如：

Pod 什么时候会“失败”？

• initialDelaySeconds+ ( periodSeconds* failureThreshold); 或者
• initialDelaySeconds+ ( MAX( periodSeconds, timeoutSeconds) * failureThreshold);

当 Pod 成功时，同样的问题也适用。

我正在为我的 kuberenetes 部署配置就绪和活跃度探针。

这是我添加它的方式：

但这会导致 pod 中的错误日志：

如果我删除探针并创建部署，则不会出现此日志。

我有一个入口设置，使得对该容器的所有 http 请求都作为 https。因为我的容器只需要对它的 https 请求。

我认为显示此错误日志是因为 tcp 探测器未在此处发送 https 请求。

有没有其他方法可以在没有这些错误日志的情况下设置探针？

我有一个简单的 spring boot 应用程序，带有以下 liveness probe：

在 health 端点中，我只是抛出了一个异常，导致它返回 500。这是一个新的 Pod 在观看多次重启后的统计数据：

我注意到前几次重新启动就像预期的那样快。然后#3、#4、#5 相隔 1 分钟。到目前为止有点道理。之后，我开始看到 CrashLoopBackOff 并且两次重新启动之间的时间间隔长达 5 分钟。为什么 CrashLoopBackOff？为什么在几次重启后重启相差如此之大？

我看到了吊舱的日志。没有什么不寻常的。日志输出是这样的（这些日志是在多次重启后）：

当我运行 describe 命令时，我看到类似

顺便说一句，在这 5 分钟内，pod 保持在CrashLoopBackOff状态。我已经多次重新启动 pod。我每次都看到相同的行为。

活跃度探测应该触发失败容器的重启。他们是否尊重默认的有状态集部署和扩展保证。例如，如果在同一个状态集中的多个 Pod 的活跃度探测同时失败，K8S 会尝试一次重启一个容器还是同时重启所有容器？

在使用 minikube 在 Kubernetes 上部署微服务时，我遇到了 Liveness probe 失败的问题。基于这个答案，我将 liveness 探测的 timeoutSeconds 从 1 更改为 10，但问题并没有解决。就绪探测失败：超时：未能在 1 秒内连接服务“：8080”

错误说，

我还能做些什么来解决这个问题？

我有一个应用程序部署到 Kubernetes，它依赖于外部应用程序。有时这两个之间的连接会进入无效状态，这只能通过重新启动我的应用程序来修复。

为了进行自动重启，我配置了一个活动探针来验证连接。

这一直很好，但是，我担心如果外部应用程序出现故障（例如连接错误不仅仅是由于无效的 pod 状态），我的所有 pod 将立即重新启动，我的应用程序将变为完全不可用。我希望它继续运行，以便不依赖于不良服务的功能可以继续。

我想知道吊舱中断预算是否会阻止这种情况，因为它会由于“自愿”中断而限制吊舱的数量。但是，K8s 文档没有说明活性探测失败是否是自愿中断。他们是吗？