问题标签 [readinessprobe]

我的应用程序有一个有效的 Kubernetes 部署。

当我应用我的部署时，我可以看到它运行正常并且应用程序响应了我的请求。

应用程序有缺陷并在某些情况下崩溃。我“调用”了这样一个条件，然后在 pod 事件中看到以下内容：

预计活性探测失败并重新启动容器。但为什么我会看到Readiness probe failed事件？

我有一个应用程序，它为 REST 请求提供服务器，并且正在侦听 Kafka 主题。我将应用程序部署到 Kubernetes 并像这样配置就绪探针

基本上遵循[configure-liveness-readiness-startup-probes]的说明

部署完成后，我可以看到 Pod 就绪探测失败

这是意料之中的。然后我向该主题发送了一条kafka消息。我观察到

1）我的应用程序已使用 kafka 消息并保存到数据库。
2）其余的api无法访问。

我假设如果 pod 的就绪探测失败，应用程序既不能接收 kafka 消息也不能接收 rest 请求。但是为什么在我的测试中，REST 请求和 Kafka 消息的处理方式不同。

根据 Kubernetes 文档：

但它并没有明确说明它真正意味着什么样的流量。如果就绪探测失败，kubernetes 是否只限制到 pod 的 http 流量，但不限制 tcp 流量（因为 Kafka 正在通过 tcp 工作）？

我的实际意图是让我的服务应用程序（kafka 消费者）能够控制何时接收 kafka 消息（以及 REST 请求）。例如，如果操作繁重，我的服务将删除 /tmp/healthy 文件，从而使 pod 无法准备好接收 kafka 消息和 Rest 请求。当繁重的操作完成后，应用程序会写入健康文件以使 pod 准备好接收消息。

更多信息，在我的测试中，kubernetes 版本是 v1.14.3，并且 kafka 代理在 kubernetes 之外的一个单独的 vm 中运行。

我的环境是：Ruby on Rails、Vue.js、Webpacker 和 Kubernetes。

我在我的 K8s 部署中添加了用于运行状况检查的 readinessProbe，但是 pod 无法准备好启动，因此我使用以下命令检查了日志：

然后我能够收到一条消息

但是，当我在本地主机中检查此路由时，没有错误并且 HTTP 状态为 200

在 K8s 吊舱中。

我进行了 readinessProbe 健康检查，因为我在入口中获得了不健康状态。

这是我的 YAML 文件：

mysql.yaml：

webpacker.yaml

rails.yaml：

kubectl describe po <pod_name> -n <namespace>：

我很难理解哪个最适合我的情况以及如何实际实施它。

简而言之，问题是这样的：

• 我正在使用 Skaffold 启动我的 DB (Postgres)、BE (Django) 和 FE (React) 部署
• 大约 50% 的时间 BE 在 DB 之前启动
• Django 尝试做的第一件事就是连接到数据库
• 它只尝试一次（根据设计，不能更改），如果不能，它会失败并且应用程序被破坏

• 因此，我需要确保每次启动部署时，在开始 BE 部署之前数据库部署正在运行

我遇到了readiness、liveness 和 starup probes。我已经阅读了几次，就绪探测听起来就像我需要的那样：我不希望 BE 部署在数据库部署准备好接受连接之前开始。

我想我不明白如何设置它。这是我尝试过的，但我仍然遇到一个在另一个之前加载的实例。

postgres.yaml

api.yaml

客户端.yaml

我不认为ingress.yaml和skaffold.yaml会有帮助，但如果我应该添加这些，请告诉我。

那么我在这里做错了什么？

编辑：

因此，我根据 David Maze 的回应尝试了一些方法。这有助于我更好地了解正在发生的事情，但我仍然遇到一些我不太了解如何解决的问题。

第一个问题是，即使使用 default restartPolicy: Always，即使 Django 失败，Pod 本身也不会失败。即使 Django 失败了，Pod 仍认为它们非常健康。

第二个问题是显然需要让 Pod 了解 Django 的状态。那是我不太关心的部分，特别是探测器应该检查其他部署的状态还是它们本身？

昨天我的想法是前者，但今天我认为是后者：Pod 需要知道其中包含的程序已经失败。但是，我尝试过的所有操作都会导致探测失败、连接被拒绝等：

所以显然我设置了错误的探针，尽管它是一个“超级简单”的实现（正如一些博客所描述的那样）。例如，/health和/healthz路由：这些是内置在 Kubernetes 中还是需要设置？重读文档以希望澄清这一点。

我有一个侦听端口 8000 的 Pod。当我添加就绪探针并重新部署时，检查失败并显示消息“就绪失败，http 状态 404”

我将准备检查的值设置如下

当我在我的入口（负载平衡器）开始监听之前描述我的 pod 时，检查返回 404。或者至少我相信是这样，因为我看到（kubectl get svc）中的 LB IP 在几分钟后出现。

使用 HaProxy 作为入口控制器时在 Kubernetes 集群上。当旧的 pod 死亡时，HaProxy 将如何添加新的 pod。

它是否可以确保 pod 已准备好接收流量。

现在我正在使用就绪探针和活跃度探针。我知道 Kubernetes 中使用新 pod 的顺序是首先 Liveness probe --> Readiness probe --> 6/6 --> pod is ready。

那么它会使用与 HaProxy Ingress Controller 相同的 Kubernetes 机制吗？

我对 k8s 很陌生，如果问题没有意义或不正确/愚蠢，我深表歉意。

我为我的 pod 定义配置了一个活跃度探针，它只是命中一个健康 API 并检查它的响应状态以测试 pod 的活跃度。

我的问题是，虽然我理解 liveness/readiness 探测的目的......它们到底是什么？它们是否只是另一种类型的 pod，它们被旋转起来尝试通过配置的 API 与我们的 pod 通信？或者它们是某种在 pod 内部运行并尝试 API 调用的轻量级进程？

另外，探针如何与 pod 通信？我们是否需要为 pod 配置服务，以便探针能够访问 API，或者它是不需要额外配置的内部进程？

我正在为多个租户设计一个具有单个 kubernetes 部署的系统，但每个客户有多个数据库、队列等。任何无状态的东西都是共享的，任何有状态的东西对于每个租户都是分开的。根据请求主机（tenant1.company.com 或tenant2.company.com），代码将连接到相应的数据库和队列。

在这种情况下，我的 pod 设计为为多个租户工作，应该如何设计就绪探针？

我可以想到以下选项，但似乎都不正确：

1. 连接所有的数据库和队列，看看是否准备好了： 缺点：这会导致 pod 没有准备好，即使一个资源宕机了。
2. 连接到任何一个数据库和队列： 缺点：并没有真正检查所有探测器的准备情况。
3. 根本没有任何就绪探测。

感觉如果我在资源级别进行分离以支持多个租户（这是一个 B2B 多租户，需要时间和精力来加入新租户），我还需要在 Kubernetes 部署级别进行分离。

这是标准方法吗？要么在所有级别上完全分离，要么拥有一个具有相同共享资源的统一系统？如果没有，我该如何设计就绪探针？

我有一个简单的 OpenShift 设置，服务配置了 2 个后端 PODS。PODS 已配置其就绪探针。该服务通过 NodePort 公开。所有这些配置都很好，它按预期工作。一旦就绪探测失败，服务会将 pod 标记为不可访问，并且任何新请求都不会被路由到 POD。

场景 1：我执行 CURL 命令来访问服务。在执行 curl 命令时，我引入了 Pod-1 的就绪失败。我看到没有新请求发送到 Pod -1。这可以

场景 2：我有 Java 客户端并使用 Apache Commons Http 客户端库来启动与 Kubernetes 服务的连接。连接建立并且工作正常。当我介绍 Pod-1 的就绪失败时，问题就来了。我仍然看到客户端仅向 Pod-1 发送请求，即使服务只有 Pod-2 的端点。

我的直觉是，由于 HttpClient 在通过 NodePorts 公开时使用持久连接和服务，所以 Http 连接的目标地址是 POD-1 本身。因此，即使就绪探测失败，它仍然会向 Pod-1 发送请求。

有人可以解释为什么他们按照上面描述的方式工作吗？

我们有一个 statefulset，我们希望有最短的停机时间（就像我想的任何其他 statefulset 一样），但是由于就绪探测失败阈值为 5，因此 pod 卡在“终止”状态（在“终止”状态期间增加了 5 秒的停机时间没原因）。因此，为了更快地终止，我将故障阈值降低到 1，它现在终止得更快，但是现在故障阈值如此之低，由于 CPU 达到 100% 或其他瞬态，它偶尔会导致随机未就绪的 Pod问题。

我的问题：如何使 Pod 更快地终止，同时保持 Readiness 故障阈值较高，以减少 Pod 重启期间的停机时间？（另外，我希望有任何其他随机提示可以使 pod 更快地重新启动（例如，在ContainerCreating中花费更少的时间）