问题标签 [readinessprobe]

在 Spring-Boot 2.4 中，Actuator 健康端点和就绪探测存在这个问题。当我的自定义关键组件之一关闭时，/health/readiness端点说DOWN和/health端点也是，但细节readinessState仍然/health说UP。

为什么会这样？也不应该readinessState说DOWN？

我在网上找到的许多教程似乎都没有解决这个问题。

我的假设：这readinessState与准备情况无关，而是暴露了另一条信息。我希望我错了，因为这毫无意义，而且我对代码的理解似乎另有说明。

更多关于我的配置：

相关摘录自application.yml

当我做myCustomgo时DOWN，会出现以下结果：

GET /health

GET /health/readiness

我想在需要 20 秒的 pod 内运行 bash 脚本。去完成。我希望 pod 准备就绪并仅在该脚本完成后添加到服务端点。我怎样才能做到这一点 ？

在 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 请求。

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

以下是我的应用程序 helm 图表中的探针配置

当我部署时，在 deployment.yaml

但在 pod.yaml 中，它是

然后在 pod 中给出以下错误：

`Readiness probe failed: Get http://IP:15021/healthz/ready: dial tcp IP:15021: connect: connection denied spec.containers{istio-proxy}

警告 Liveness probe failed: Get http://localhost:15020/app-health/app-name/livez: dial tcp 127.0.0.1:15020: connect: connection denied spec.containers{app-name}

警告准备探测失败：获取 http://localhost:15020/app-health/app-name/readyz: dial tcp 127.0.0.1:15020: connect: connection denied spec.containers{app-name} `

为什么 pod 使用不同的路径和端口进行探测，但未能给出上述错误。有人可以帮我解决缺少的问题吗？

我正在使用 Exec 探针添加活性探针和就绪探针。
我的配置如下所示：

当上述一个不起作用时。我对此进行了修改并尝试了：

在运行kubectl describe pod时，得到以下输出：

我尝试了另一个应用程序，我正在运行grpcurl它来调用健康检查：

kubectl describe pod在为这个而奔跑时，我得到了：

这两个都失败了。问题是，我如何编写一个Exec probe包含管道（或多个管道）的 .

我正在使用 EKS v1.18。
（以上两个配置属于不同的应用程序。）